FILENET P8 The Synergy Between BPM

FILENET P8 The Synergy Between BPM & SOA

WHITE PAPER August 2006

www.filenet.com page 2

FILENET The Synergy between BPM & SOA August 2006

1. Executive Summary.......................................................................................................................................................... 3

2. Challenges for Business and IT.......................................................................................................................................... 3 2.1. Business Needs Execution and Agility ..................................................................................................................................................... 4 2.2. Enterprise IT Complexity .............................................................................................................................................................................. 4

3. BPM and SOA Meet the Challenges.................................................................................................................................... 6 3.1. BPM for Process Efficiency and Improvement......................................................................................................................................... 6 3.2. Web Services and SOA for Reuse and Agility........................................................................................................................................... 7 3.3. BPM and SOA Together ................................................................................................................................................................................ 8

4. Designing Services and Processes ................................................................................................................................. 10

5. A Modern Enterprise with SOA and BPM........................................................................................................................... 11

6. Web Services ................................................................................................................................................................. 11

7. Components of SOA and BPM......................................................................................................................................... 13 7.1. SOA Components and Functionality ........................................................................................................................................................14 7.2. BPM Components and Functionality........................................................................................................................................................15

8. Business Events and Rules in BPM and SOA................................................................................................................... 16 8.1. Events in SOA.............................................................................................................................................................................................. 16 8.2. Events in BPM and BAM.............................................................................................................................................................................17 8.3. Business Rules and BRMS........................................................................................................................................................................18

9. FileNet BPM and SOA...................................................................................................................................................... 18 9.1. FileNet BPM Suite ........................................................................................................................................................................................18 9.2. SOA Functionality in FileNet BPM.............................................................................................................................................................. 19

9.2.1. FileNet BPM Web Services API ....................................................................................................................................................... 19 9.2.2. FileNet BPM Consumes Web Services........................................................................................................................................... 19 9.2.3. FileNet BPM Publishes Web Services ............................................................................................................................................ 20 9.2.4. FileNet BPM Complies with Web Services Standards .................................................................................................................. 20 9.2.5. FileNet BPM Provides a UDDI and its Interface ............................................................................................................................ 20

10. Conclusion: Leveraging BPM and SOA........................................................................................................................... 20

Appendix: Glossary............................................................................................................................................................. 22



1. Executive Summary

Increasing business efficiency and agility in the face of competitive pressures, shrinking profit margins, and changing business conditions such

as compliance with new regulations, are top challenges and priorities for large organizations. This in turn translates to challenges for the

enterprise IT which must reduce complexity and be more responsive to the business needs. To address these challenges, there are two

related disciplines and technologies that organizations have turned to: Business Process Management (BPM) and Service Oriented Architecture (SOA).

In recent years, BPM has emerged as a significant market. According to leading analysts BPM market was $1.25 B in 2005, with an annual

growth of about 20%. BPM products (typically referred to as BPM suite or system or simply BPMS) have emerged as a significant software

product category. In the recent years, many software vendors from various backgrounds – pure-play, workflow, middleware and application

integration, and platform – have developed and launched BPM products. Research also indicates that deploying SOA is a top priority for many large organizations. New SOA related software such as Enterprise Service Bus (ESB) has emerged a market of its own.

BPM is the key discipline and technology for automating, managing, and improving business processes across various organizations. SOA is

concerned with producing and managing reusable business services from IT systems or as new services, then using them to build (compose) agile business applications faster.

BPM and SOA also have different characteristics. In general, SOA is somewhat lower-level, development-centric, and technical, while BPM is

higher-level and business-oriented. But BPM and SOA have similarities (e.g. both deal with business processes), and more importantly they

are complementary. Business processes managed by BPM can use (consume) business services that are defined and managed using SOA.

This helps make business processes more flexible and agile. At the same time, building useful high-level business services and composite

applications in SOA often requires orchestration that is in the realm of BPM. BPM and SOA together can help reduce IT complexity, realize

rapid application development (RAD), and accelerate process automation across the enterprise.

This paper provides an introduction to SOA and BPM, but it is not an exhaustive description and explanation of either, as much has been

written about these concepts and technologies elsewhere. Here we primarily explore the relationship between BPM and SOA, their similarities,

differences, and synergies, and how they complement and work with each other. We argue that both are important and required. Ultimately to reap the full benefits of one, the other must be utilized.

We then look at how FileNet BPM suite meets SOA requirements and interoperates in an SOA environment. FileNet BPM provides a

standards-compliant Web services API to its process engine. Processes in FileNet BPM can consume external Web services. The processes

themselves can be published as Web services to be consumed by other services or processes. FileNet BPM also includes a UDDI registry for

Web services as part of its process engine. Furthermore, FileNet BPM implements and complies with specific Web services and security

standards to provide secure and reliable messaging across various services. FileNet BPM can help organizations realize the BPM-SOA

synergy and its benefits.

2. Challenges for Business and IT

Here we look at the challenges that organizations face. To meet the business goals and objectives, business must efficiently execute its

business processes, have access to the right information, and respond to changing business conditions. To do so, IT must provide the business with the needed infrastructure, tools, and applications.

Enterprise IT is very complex which makes it difficult to change and respond to the changing business needs. Matters are made more

complicated in this cross-organizational communication because of the divide between business and IT. What IT builds may not be what the



business wants or may not fully meet the business requirements. Business may not understand the technology and the technical challenges

that IT faces, while IT may not have the insight to appreciate the business issues and challenges. Business often accuses IT of being slow and

inefficient in responding to the business needs such as deploying or upgrading to a new CRM system. IT may perceive the business people as being inept in understanding technology.

Hence the IT complexity and the divide between business and IT may adversely impact the overall business performance, because changing business needs are not met by IT in a timely fashion.

2.1. Business Needs Execution and Agility

Businesses face continuous pressure to reduce operating cost, increase productivity and revenue, while improving the quality of products and

services and increasing customer satisfaction. To address these requirements, businesses need to automate and optimize their business

processes and how they execute them.

Such business processes may involve people (employees, customers, partners), and multiple systems and applications. They may be manual

or partially automated and thus inefficient. Information, the business logic, and the knowledge and skills to carry out a business process are

distributed across various people, systems, and geographies. These processes are difficult to manage. Business managers who own these

processes also need to better control their processes and have visibility over them, which is very difficult to do with business processes that are

fragmented and not centrally managed.

Businesses also require agility. Due to changing business conditions and business models, competitive pressures, regulatory and compliance

issues, and mergers and acquisitions, organizations must adapt and change in real-time.

2.2. Enterprise IT Complexity

Meeting the changing business needs requires unprecedented responsiveness from business and in turn from IT to be able to build and deploy business-critical applications and services while leveraging existing IT investments.

Today’s IT organization is complex, consisting of many different applications and systems built using heterogeneous technologies, on various

middleware, using multiple databases, and running on many platforms. The maintenance of and change to any of these systems may be very

resource intensive and expensive. It requires that the IT staff be well-versed in a wide range of technologies, programming languages, and

commercial products that in many cases are proprietary.

Such an IT environment is made up of various commercial and in-house proprietary applications (e.g. ERP, CRM, and SCM). These

applications tend to use various technologies and architectures. Some may be host-based built in COBOL without a separation between UI and

logic and without any API. Certain others may be client-server written in C/C++, while others may be more modern 3-tier Web-based

applications built in J2EE or .NET technologies. Each application potentially has its own database. Some may use middleware while others

may not. Figure 1 below shows the heterogeneity and the associated complexity in a typical enterprise IT.



Figure 1. Enterprise IT is heterogeneous and complex.

Each such application typically automates certain business processes, or more often a segment of a larger business process that if realized

end-to-end, spans multiple applications and organizations. In the case of commercial packaged applications these processes are usually well-

understood and common. Such applications are configured and customized to fit the business usually by a large consulting team during a long, laborious, and expensive development and deployment, before they go to production.

The business people who own these business processes, have little control over managing their processes in these systems. These

applications tend to be rigid, fixed, and inflexible. It is difficult to integrate with these systems in a systematic and scalable fashion.

Furthermore, when there is a need for a new service or application, it is difficult to reuse functionality from these applications. Any change must go through complex and time-consuming IT activities.

Things get worse with legacy such as mainframe applications. These systems contain a significant amount of the mission-critical data and logic

that many large organizations still run on today. This information is particularly difficult to access and reuse, as these systems are developed in older technologies. It is not practical or even possible to do away with them. There must be an easy way to reuse such data and logic.

In essence, automated processes are locked up inside these applications. Each such suite of applications forms a silo of automation with its

own database, business logic, and UI. There is also redundancy in data and logic across these silos. For example, information about a

customer, an order, or a part for a product, may reside on multiple systems. There are also cross-silo associations. For instance, an order in

one silo is associated with a customer that resides in another. Update or change to one entity in one silo may require changes to multiple applications and databases in other silos. Figure 2 below provides a simplified view of the typical application silos.



Figure 2. Application silos with hidden and inflexible processes

Hence there is a dire need for integration across these silos. The useful functionality in these silos must be exposed so that they can be reused

in building new business applications and services easily and quickly. IT must provide the infrastructure and tools for automating and managing

the business processes end-to-end while they leverage information and logic from existing applications. The resulting system must be

accessible and usable by business users. It must also provide the means for measuring business performance so that business managers can monitor how well they are executing against the business strategies and corporate objectives.

3. BPM and SOA Meet the Challenges

Here we discuss how BPM and SOA each addresses the needs of business and in turn the requirements of IT. Each meets certain needs, but by utilizing both together, we can realize far more profound benefits.

3.1. BPM for Process Efficiency and Improvement

BPM enables organizations to streamline and automate their business processes across the enterprise thus increasing productivity and

reducing the cost of running those processes. By managing customer-facing business processes using BPM, organizations can also increase

customer satisfaction and retention.

BPM allows organizations to model, automate, and optimize their business processes that involve people (i.e. employees, customers, and

partners) and systems. A business process is a multi-step business activity that typically involves several people and systems, such that each

activity is performed by a person or by a piece of software (e.g. a Web service). In some cases a business process may be heavily system-

centric and have few or no human participation, or it may be highly collaborative and human-centric with few or no system activities. For every

human activity, a user interface is defined that may be browser-based, e-mail, or mobile based. The activities in a business process are typically linked and coordinated subject to a set of business rules and policies.



The artifact produced by a BPMS is a business process application. Since business processes are modeled and designed in a visual

environment in a BPMS, the development cost is significantly reduced in comparison to writing code. BPM also enables business people to

have visibility and control over their processes allowing them to monitor and measure their process execution and have a say in improving their

processes. Thus BPM can help close the gap between business and IT. It enables better tracking, monitoring, and measurement of business

activities and processes. Because the business processes and rules have visual representation in BPM, it becomes easier to monitor and

measure business activities and performance. And when there is a need for change, it is easier to modify and evolve the business processes and rules in BPM. This makes a business more agile and responsive to business changes – planned or otherwise.

The way a company runs its operations and conducts its business is essentially captured in its modeled and automated business processes.

Organizations differentiate themselves and create competitive advantages through the uniqueness of their business processes. BPM enables

organizations to build that uniqueness into their business processes. Unlike packaged applications that typically lock up the business

processes in the applications, BPM puts the business analysts and business managers (the real stakeholders) for the business processes in

control and in charge of their business processes. While IT will be involved in implementing BPM, the business people become closer to

understanding, defining, and managing their own processes. BPM also provides an effective way for doing knowledge transfer as processes

become well-documented business artifacts that employees can get trained on.

As discussed later on in this paper, FileNet BPM is a comprehensive BPM suite of products that provides enterprises with full BPM functionality

and its benefits outlined here.

3.2. Web Services and SOA for Reuse and Agility

The business processes to be managed by BPM must integrate with existing applications and systems. They require access to the functions

that are locked in the applications silos. Hard-coding point-to-point integration with those applications is not a good solution as it creates tight

coupling with the application and makes the process brittle and inflexible. Every time the application changes, the integration point may have to

change as well. A change in the process may also break the integration point.

SOA and Web services provide the key to unlocking the silos and exposing the functionality within those silos. Using SOA technologies, useful

functions within those business applications can be captured and packaged as loosely coupled, autonomous, and reusable components

typically in the form of Web services. A Web service has a published interface (contract) that specifies how it is to be used. A consumer of that service simply needs to know about that interface that is published in a standard format.

These services are then stored and registered in a directory service so that all interested and authorized parties can use and reuse them.

Figure 3 below shows that services from the previously monolithic silos of automation are generated and exposed. Commonly used activities,

transactions, process segments, and functionality from the back-end systems are captured as reusable components such as J2EE and .NET

components, or preferably Web services. These services are registered and stored in a service registry for reuse. These services can be reused in defining new business processes along with new services.



Figure 3. Services generated from application silos and reused in a business process

Mapping all the API calls from various business applications to Web services may be just the very first step in transitioning to SOA. Such

services are typically very low-level and do not provide much business value. To provide more useful and business-oriented services, low-level

services may be orchestrated and composed into higher level business or composite services. For example a customer address change

service may be a composite service that is made up of four low-level services for changing street, city, state, and zip code. There must be an orchestration component in SOA for this purpose.

Some composite services may in fact be full-fledged applications called composite applications. A composite application is a software

assembly that implements a (possibly single) business function (potentially a segment of a larger business process). Its components access

data and business logic from multiple back-end systems. Composite applications can help transform old and legacy business applications to

more modern technologies. For example, multiple legacy applications used for a particular business process can become a single uniform Web-based application.

Because of the reuse of back-end data and logic, the development cost for composite services and applications is lower than the alternative;

i.e. building new applications ground-up. This reuse reduces the time required for building new applications and in turn reduces the total cost of

ownership (TCO) for such applications.

3.3. BPM and SOA Together



The business services may not be very useful by themselves. Their value is realized in reuse across various composite applications and

processes. They are often composed, assembled, or orchestrated using BPM to create higher level business services or composite

applications.

In turn the business services that are generated from Web services orchestration may be used in business processes that typically include

human activities. Such processes can be modeled and automated using BPM. FileNet BPM allows business processes to explicitly consume and ingest Web services.

Figure 4 below shows that fine-grained, low-level services are composed to form coarse-grained composite services that have more of a

business context. A BPEL-based orchestration engine might be used for such composition. BPEL in its pure form does not handle human

activities. It is strictly for the orchestration of Web services. However, most general-purpose BPM such as FileNet BPM can also handle this

service orchestration equally well. The composite services in turn may be consumed by business processes that involve human participation.

BPM process languages typically have explicit constructs for handling human activities. One such language is XPDL that is becoming widely acceptable standard for human-centric BPM.

Having a common language for defining business processes is important because this will help make business processes portable across

different BPM systems. There might also be a need for integration and interoperability across various BPM systems. Such a standard will also

drive development of standards based process design tools.

Figure 4. SOA and BPM together to orchestrate services and manage processes

An important aspect of BPM and SOA relationship is that typically the processes (or an entry point to them) that are defined in BPM can be

published as a Web service. Such a service then can be consumed by other services in compositions and orchestrations or by other business

processes in BPM. Therefore BPM and SOA form a bi-directional and recursive linkage in terms of publishing and consuming Web services:

Web services (in SOA) may be consumed by business processes (in BPM). In return, business processes in BPM can be published as Web services and consumed by other services or processes.



FileNet BPM allows BPM processes or a step in the process to be published as a Web service that in turn can be used by other services or processes. FileNet BPM also provides a Web services registry where such as service can be stored and registered for reuse.

By using SOA and BPM technologies together, organizations can achieve better IT and business results than are possible by either SOA or

BPM alone. SOA promotes reuse and makes business processes more flexible. BPM provides richer and higher level business processes that

in turn become services.

4. Designing Services and Processes

How do we design and implement SOA and BPM? Do the services come first or the processes? We may start with building services. We take

all applications and break them down to services (e.g. mapping the APIs) to services. We may also define new services that we think may be

useful. This is a bottom-up approach. We may compose some of these services to create higher-level services. All these services are stored

in a registry to be used by the authorized users. Then when we model and design our processes, we can hopefully find the services that will be

needed in the registry. The problem with bottom-up design is that a service may not exactly do what a process needs or it may not provide the correct interface. We will then have to change the service or define a new mutation of it.

Alternatively we start with modeling business processes in BPM from high-level. As we work out the details we identify needs for touch point to

other systems or new computing resources that can be services. We assume the required service interfaces and proceed with process

modeling and design. So the business process dictates the services that we need to complete the processes. When we get to designing a

needed service, we may break it down to lower-level services. This approach is top-down. It is business-driven and results in creation of services that are important and needed with the proper interfaces.

Figure 5 below depicts the concepts of bottom-up and top-down design in the context of services and processes.

Figure 5. Designing services and processes



In reality most often a combination of both top-down and bottom up design in an iterative manner is used. We may design some services which

we know will be useful, generic and reusable. At the same time high-level process modeling activities will point to the need for specific other

services. Various groups may collaborate and iterate over this process till they come up with an optimal process definition and the services that

such as process consumes. After the initial deployment, by monitoring the process performance, areas for improvement may be identified that

may result in further refinement of these processes and services to achieve both service and process optimization.

5. A Modern Enterprise with SOA and BPM

The main construct in SOA and BPM are services and processes respectively, though this distinction becomes less relevant as business

processes themselves may be published as services. From a high-level perspective, SOA manages business services and BPM manages

business processes. Business processes are made up of business services, which may include human activities as well as other business

processes. Business services in turn are made up of lower level services that may be tied to computing infrastructure and leverage existing

EISs (enterprise information systems).

Figure 6 below depicts a high-level view of a modern enterprise where there is a business service layer on top of the IT infrastructure. These

business services may be composed of lower level services that leverage the resources in the infrastructure. This service layer is defined and

managed by SOA. There is also a process layer over the service layer which leverages the business services below to create highly flexible and agile business processes. This layer is defined and managed by BPM.

Figure 6. A modern enterprise with SOA and BPM

6. Web Services

The very core element in SOA and also relevant in BPM is reusable software component that is called a service which implements a useful

functionality. A key feature of a service is that it provides a published interface that specifies how it can be used. The interface or contract

specifies what information is passed and what it returns (if anything). Using encapsulation the details of the implementation and the language

used are hidden from the potential user. The implementation in fact may change at some point, but as long as the interface remains the same,

any client using it doesn’t have to change. So a client consuming a Web service, only needs to be concerned with what the service does (interface) and not how it does it.



There are different technologies that provide reusable components or services. Such a service may manifest itself as a .NET assembly, a

CORBA object, a Java component in J2EE, or as a Web service. Each of these provides its own interface definition language and the protocols

it supports. However, Web services are the primary technology used in SOA. Web services have important characteristics that make them the

ideal building block for SOA. Web services are loosely coupled in the sense that there is no tight coupling between a client and the Web

service it calls. Web services also enjoy location transparency. It is not important where a service is located. In fact the location of a service

that is in use may change without breaking anything.

The key standards and elements in working with a Web service are:

• WSDL (Web Services Definition Language) defines the interface for a Web service

• SOAP (Simple Object Access Protocol) defines the encoding for messages that sent to and received from a Web service

• UDDI (Universal Description, Discovery, and Integration) is a registry and directory services for storing and retrieving Web services; it

is essentially a white/yellow pages for Web services

• HTTP/HTTPS: HTTP and Secure HTTP are the primary transports (transfer protocols) supported by SOAP; SOAP also supports

SMTP (e-mail protocol).

Figure 7 below shows how a basic Web service is used. A client looks up a Web service from UDDI registry and obtains its WSDL. It then invokes the Web service.

Figure 7. The workings of a basic Web service

The Web service may be synchronous in which case the client waits (blocks) till it receives a reply message from the Web service. The Web

service may be asynchronous in which case the client proceeds after the invocation and the Web service responds at a later time, if a response is defined for it.



Synchronous vs. asynchronous communication is one of the fundamental concepts in SOA. Synchronous communication closely maps to

composition while asynchronous communication ties to integration. The figure below conveys this concept. Figure 8(a) shows a basic

application of asynchronous communication and contrasts it with an application of synchronous communication in Figure 8(b).

Figure 8. Asynchronous vs. synchronous communication

Both synchronous and asynchronous communication models are essential and must be supported. Asynchronous communication is the

foundation of Event-Driven Architecture (EDA), a close relative of SOA though a far less popular topic. It is discussed in some detail later in this

paper.

There are many important standards for Web services that must be implemented and complied with. For example, Web services Reliable

Messaging (OASIS WS-ReliableMessaging) standard that as evident from the name is concerned with reliable messaging among Web

services. It provides guarantee of message delivery between Web services for a given criteria. For example a message must be delivered at

least once, at most once, exactly once, or in order. FileNet BPM in fact implements this standard so that the Web services generated by

FileNet BPM provide reliable messaging. That is Web services defined in FileNet BPM comply with WS-ReliableMessaging.

Another important Web services standard is Web services Security (OASIS WS-Security) which defines security functions for Web services

such as authentication and association of security tokens with messages.

7. Components of SOA and BPM

In this section we define the typical components and functionality that comprise SOA and BPM. Figure 9 below shows the high-level

components and functional areas that make up each one. Note that this figure is general and not specific to any one vendor. The components in actual product suites may be different.



Figure 9. Components of BPM and SOA

It is important to note that there are similarities and overlap between SOA and BPM. For example BPM and SOA overlap as they both involve

process management or orchestration. They both have repositories for services and processes. They both have development, modeling, or

design tools (typically IDEs) for defining artifacts such as services and processes. They both have monitoring and management functionality for

services and processes. And they both deal with similar security issues. Another important characteristic of BPM and SOA is that they both are event-based; they can publish and consume events. This topic is discussed in more detail later on.

There are capabilities that are unique to each one that makes them different. Or there are overlapping areas that are more developed in one

than the other. For example, process simulation and BAM primarily exists in the BPM world. SOA can also benefit from such technologies. There is no reason why Web services cannot be simulated, or why BAM cannot monitor Web services.

They are different in the sense that SOA is somewhat lower-level and more technical than BPM. SOA typically deals with Web services while

BPM deals business processes that are made up of services and other elements such as human activities. BPM is more geared towards

business users than SOA. It typically has process modeling tools that a non-IT person can use to model business processes. Hence BPM is business-driven, while SOA is IT-driven.

While there are interoperability points between the two (e.g. services being consumed by processes), the focus and core competency of most

relevant vendors are only in one of the two – BPM or SOA. The related standards are not only independent of each other but may also

compete with each other (e.g. BPEL vs. XPDL). Similarly organizations are most likely to pursue initiatives in BPM or SOA independent of each

other.

7.1. SOA Components and Functionality

The key components and capabilities in SOA are as follows:



• Development: A visual and drag-n-drop IDEs for building Web services and defining their interfaces, transformations and service

orchestrations.

• Adapters: Connectivity to various back-end systems such as ERPs and CRMs, databases, legacy applications.

• Transformation and Routing: For data transformation and mapping; e.g. mapping an XML document from one format to another

based on an XML schema. It is typically based on XSLT, XQuery, and XPath. May be a part of the ESB in some product suites.

• Orchestration: Typically a BPEL-based server for defining processes that are made up of Web services. There may be an

associated visual designer that is part of development.

• Enterprise Service Bus (ESB): A message queue that provides message queuing, guarantee message delivery, routing, event

management. The definition of ESB has been changing and it is starting to include other important capabilities such as transformation

and mapping and even orchestration.

• Governance and management: To manage Web services, monitor (business-level) their usage, manage service level agreements

(SLAs), policy management, version control, etc. This becomes very important with a large number of Web services (e.g. more than

50), which is a given in any sizable organization.

• Security: Deals with authorization, authentication, single sign-on, digital signatures, and other security issues for Web services; may

be covered by governance and management component in some products.

7.2. BPM Components and Functionality

The key components and functionality of a BPMS are described here. Note that FileNet BPM provides all these components in an integrated product suite.

• Modeler: A visual tool for creating process models ideally in BPMN standard, targeted for use by non-IT and business analysts. The

artifact produced from modeling is a process model that can potentially be analyzed and simulated. It must accommodate both

system (service) and human activities.

• Designer: A visual tool that may be integrated with an IDE or be Web-based for defining process applications. It must accommodate

both system (service) and human activities. It typically is integrated with the Modeler. In some cases both functionality may be

provided by the same integrated tool. Design activity tends to be more technical as it involves defining integration points. The

outcome of design activity is an executable (process) application that can then be deployed onto a process server.

• Simulation: A typically visual component usually with animation capabilities that given a process model and a set of parameters can

simulate a process and produce reports that can be used for what-if analysis to optimize a business process before going to

production. It typically can be fed real process execution data. Simulation is usually not a part of SOA product suites.

• Process Server: The core serve that enacts and executes process models. This is the heart of a BPM system. It must be scalable

and highly available (provide fail-over and clustering) to be able to handle large volumes of processes and transactions, and be

trusted in running core and mission critical business processes. FileNet BPM provides extensive functionality in this area.

• Repository: for storing and versioning process models. A process model may be checked out, modified and checked back again

creating a new version. It must have search functionality that provides various search criteria.



• Analytics: Provides business intelligence (BI) like functionality for doing OLAP based analysis and reporting. It may be integrated or

embedded within BPM to enable better decision making. It can also be used for analysis of historical data to identify area for

improvement and optimization. It is considered a management function.

• BAM: Business Activity Monitoring, uses event management technology to receive and process events from various sources including

the process engine, correlate the data and present it in the form of visual controls and metrics in the context of a management

dashboard. The dashboard can be customized and configured for various business users with the relevant metrics for their job

functions. Unlike analytics which deals mostly with historical data, BAM operates in near time and usually provides means for taking a

corrective action if an anomaly is observed and detected. There is little BAM functionality is the SOA world. However, BAM can help

monitor Web services by receiving usage information from Web services though an ESB.

• Management: Provides process monitoring and reporting, metrics, balanced scorecards, etc. It may have provisions for making

certain changes to in-flight processes. It has overlaps with Analytics and BAM. So they may be provided within the same

components. There is also system management functionality such as archiving processes, stopping processes, defining users and

access rights.

• Application Framework: Unlike the world of SOA which mostly deals with services, in BPM human participation is a key part of

business processes. BPM must provide a flexible and customizable presentation framework for business processes with elements

such as task list, queues, filters, prioritization, and work management. This may be a portal framework with customizable gadgets or

portlets that can be configured. An application framework may be used to further define templates for various verticals or industries

(e.g. financial services, manufacturing) as well as for horizontal areas such as HR and accounts payable.

8. Business Events and Rules in BPM and SOA

We live in an event-based world. A phone call, an e-mail, a meeting, an accident, a new order, a customer support issue, a new loan

application, an approval of a loan or claim, excess inventory or lack there of, a delay in shipment from a supplier, an acquisition or merger, a

new law going to effect, a security breach, a virus attack, etc. are all examples of events.

In a business context, the timely processing of business events is critical and is a key requirement for business agility. The ability to generate

meaningful events, process them, reflect on their impact on the business, and react to them quickly by taking the necessary action is a core

requirement. This capability provides the foundation for Real-Time Enterprise (RTE). In a process context, a rigid and fixed business process

that ignores the business events or cannot react to them and adjust accordingly may fail deliver the desired business benefits and fall short of

meeting the agility requirement.

Business Event Management (BEM) also referred to as Complex Event Processing (CEP) is concerned with the ability to publish events, listen

to events of interest from various internal and external sources, correlate the events to make business sense out of them, present them to a

business user in a comprehensible and visual form, and then swiftly initiate the proper actions (or enable the user to do so) to avoid or prevent potential losses, or respond to favorable business opportunities.

Most applications and systems do generate events and audit logs though in many cases these may be too low level for business use. For

example, network and system management software provide event management functionality but typically they deal with networking and IT

events that don’t necessarily have direct business relevance.

8.1. Events in SOA



In SOA, asynchronous Web services support events based communication. A Web service receives an event (message) and responds at a

later time. ESB as the backbone message and event bus also supports asynchronous communication among the applications and systems

plugged onto it. Hence SOA is event-based and SOA related technologies by definition support events. In fact, Event-Driven Architecture

(EDA) is an important concept that relates to SOA. EDA is concerned with systems built of components or services that exchange events or messages with each other in a loosely coupled, highly distributed environment.

8.2. Events in BPM and BAM

BPM is also inherently event-based. A BPMS generally generates or publishes events and it can also consume events. A BPMS generates an

audit trail (events) as a result of the processes being executed and tasks being performed. A typical process event may record the date/time of

a process launch or a change in the state of a running process such as a task being performed. These events tend to be in business context because they are driven by business processes.

FileNet BPM, for example, supports milestones for reporting higher level business events that have special business significance in the context

of a business process. An event such as creation of or a change to a new document (e.g. a purchase order) can also launch a business

process in FileNet BPM or change an in-flight process. By use of such event management functionality, otherwise static content in a business

process becomes active. A change in some content results in activation and changes in business processes, and business processes in turn change the associated content or result in the creation of new content.

BAM that has become an integral part of BPM, assumes an event-based foundation. It collects and correlates events, it presents the result in a

visual format with regular updates, and it can take or suggest corrective actions for defined event conditions. Such a corrective action may

result in launch of a new business process or change to an in-flight one, or invocation of a Web service.

Figure 10 below shows what event management is and what it can do. Various systems (ERP, SCM, and CRM) generate events that are

posted to an ESB. Note that these applications may also be invoked through Web services that expose their functionality and are managed by

the ESB. That is, a process in BPM may be consuming Web services from these applications. In the example shown below, under a certain events condition (from ERP and SCM) BAM will launch a process and then update a balanced scorecard in a dashboard.

Figure 10. Business event management with BPM & BAM on an ESB

An Enterprise Management System (EMS) such as IBM Tivoli may also plug into an ESB. EMS and BAM are different as an EMS typically

deals with more IT-centric events while BAM mostly operates around business events and processes. But there are certain overlaps between

the two as some EMSs provide BAM functionality nowadays. Some EMSs recently also provide Web services management capabilities which make them relevant for SOA.



8.3. Business Rules and BRMS

BPM excels in capturing and modeling structured, well-defined business processes and automating certain routing and decision making rules. There are several circumstances in which there may be a need for explicit business rules management associated with business processes.

One possible case is when there are many event sources and there are complex event matching and correlation requirements (e.g. supply

chain management for building an aircraft where there are many parts and suppliers). Or we may be interested in processing the events to

produce appropriate metrics and measurements. This is again event management and based on asynchronous behavior, similar to the

application outlined in the previous section.

Another typical use of business rules is for automating and managing complex business policies for complex decision making. For example, we

want to check on the eligibility of an applicant for a loan or auto insurance based on the supplied information. In this case, we are interested in synchronous behavior, in the sense that we ask a decision service whether an applicant qualifies and wait for a response.

In these situations use of a business rule platform or a Business Rule Management System (BRMS) integrated with a BPM may be ideal. We

can define a set of business rules using a BRMS and load it into its server (potentially an inference engine). Then in run-time the BRMS can

process the events and take the proper action (e.g. change or launch a process, or produce a metric or report), or it can process the given

query and return a decision (e.g. accept or reject a loan or insurance applicant.)

A BRMS typically provides an environment for defining declarative business rules along with an inference engine for complex decision making.

Business rules can change more often than a business process. Business rules platforms in conjunction with a BPMS may help keep business

processes simple, smarter, and more dynamic. Business rules functionality can be treated as yet another Web service that makes it suitable for

use along with BPM in an SOA environment. FileNet BPM integrates with several leading BRMSs via both direct product integration as well as

Web services.

9. FileNet BPM and SOA

In this section we take a brief look at FileNet BPMS and discuss how FileNet BPM supports Web services and SOA functionalities and

interoperate in an SOA environment.

9.1. FileNet BPM Suite

FileNet provides a comprehensive suite of BPM products. All components and capabilities discussed earlier for BPM are available in FileNet

BPM. Figure 11 below shows the main components of FileNet BPM. The base layer is FileNet Business Process Manager that contains the

Process Engine (PE), an enterprise scale BPM server, and a Web-based Process Designer. It also includes a Web application with

administrative functions as well as end-user work management capabilities.



Figure 11. FileNet BPM Suite

Other components are optional add-on products on top of BPM. BPF (Business Process Framework) provides a configurable and customizable

Web application for the presentation layer of BPM applications. BAM (Business Activity Monitor) can receive and process events from various

external sources besides FileNet BPM, process it, and present in the form of visual metrics based on different metaphors in a user-definable

dashboard. The Process Modeler is a Visio-based BPMN compliant process modeling tool that is intended for business analysts. Process models defined in the modeler can be exported to the process engine or to XPDL format.

FileNet BPM has the unique advantage that it is fully integrated with FileNet ECM (Enterprise Content Management) suite. Content plays an important role in BPM as most processes deal with various structured and unstructured content.

9.2. SOA Functionality in FileNet BPM

In this section we highlight the FileNet BPM features that support Web services and make FileNet BPM an SOA-enabled BPM.

9.2.1. FileNet BPM Web Services API

FileNet BPM implements a Web services API in WSDL to its engine that complies with WS-I (basic profile) standard. Through this API FileNet BPM in effect provides BPM services to clients in an SOA environment. This Web service API provides interfaces to:

• Retrieve a list of available work queues

• Get the elements tasks in a given work queue

• Query a queue for the elements of a particular step (an activity in the queue)

• Lock a particular field in the step and, Perform an operation on it

• Launch a process or workflow

• Retrieve milestone information for a particular process instance

• Get a list of Rosters available in BPM; roster provides information about all the process instances in a BPM.

• Query a roster for its elements

9.2.2. FileNet BPM Consumes Web Services

FileNet BPM provides explicit constructs at design time for integration with Web services. An external Web service can easily be used

(consumed) in a process by use of an “Invoke” step in the process map to bind to the Web service. The invocation may be synchronous or

asynchronous.



In a synchronous invocation, the Invoke step locks till the Web service returns with a reply message. A time-out may be specified within which

a Web service must return. The work item will wait for that time and if no response is received, then a sub-map (sub-process) may be activated

to process the time-out. In an asynchronous invocation, the Invoke step simply proceeds after calling the Web service. The Web service may respond at a later time.

In either case a Web service may return an error or fault. In such a case a sub-process may be associated with the process to handle the error condition. If the error condition occurs, then the specified sub-process (if any) is activated.

This feature allows business processes to reuse logic and data from the existing applications. It also makes processes more agile and flexible.

9.2.3. FileNet BPM Publishes Web Services

FileNet BPM has explicit constructs for publishing of processes (or steps within them) as Web services. This is achieved by use of “Receive”

step. If the intent is for a synchronous Web service, then a “Reply” step is used after Receive to handle the Web services reply. There may be several Reply steps associated with each Receive step to handle each possible reply.

Each Receive step in a process corresponds to a method in the WSDL for the Web service. When a process gets to a Receive step, it will wait till it receives a message to perform the task. If a Receive step is the first step in the process, then a message sent to it will launch the process.

This feature enables business processes defined in FileNet BPM to be reused in other applications as services. If later on the process details are changed the clients using the process as service may not have to change if the process service interface (WSDL) has not changed.

9.2.4. FileNet BPM Complies with Web Services Standards

As discuss earlier FileNet BPM Web services API complies with WS-I. FileNet BPM also implements and complies with important Web

services standards such as WS-Security, which defines Web services security functions such as authentication and association of security

tokens with messages.

FileNet BPM also implements WS-ReliableMessaging which provides guarantee of message delivery between Web services subject to some

criteria, such as a message must be delivered at least once, at most once, exactly once, or in order. As the name implies, this is an important standard to implement various policies and SLAs.

9.2.5. FileNet BPM Provides a UDDI and its Interface

FileNet BPM includes a UDDI registry for Web services so that a Web service can be stored in the process engine. FileNet BPM also provides functions to update a UDDI registry by updating or deleting a Web service.

UDDI registry for Web services is important as it is the repository for Web services. It serves as both a yellow and white pages for Web services and it facilitates the discovery and reuse of Web services, in this case business processes.

10. Conclusion: Leveraging BPM and SOA

To address the business and IT needs of today’s enterprises, SOA and BPM must be used together. SOA and its key technologies – Web

services and ESBs – provide the key elements for transforming existing IT investments into reusable services and facilitating the integration of



various applications and systems together. However the key value of these reusable services and standards-based integration is realized through reuse in the context of business processes.

Modeling, execution, and optimization of high-level business processes that involve both people and systems are the domain of BPM. As such,

BPM can help SOA drive higher value from its services. At the same time, BPM without the presence of reusable services becomes difficult

and less maintainable. BPM on SOA makes business processes more agile. BPM operates more at the business level while SOA is primarily at infrastructure and technology level. Initiatives involving both BPM and SOA will have sponsorship and backing from both business and IT.

There will be increasingly more convergence between services and processes and thus between SOA and BPM. However, given the current state of technology, BPM and SOA are not fully integrated. Hence they need to co-exist – integrate and interoperate.

FileNet BPM is a comprehensive BPM suite that provides important standards based Web services capabilities. FileNet BPM can help you in

your migration to Web services and SOA. It can interoperate with SOA products suites such as ESBs and Web services management systems. It also integrates with leading business rules using Web services.

FileNet BPM can help enterprises automate and manage their mission-critical business processes in an SOA environment, resulting in optimized business performance and business agility.



Appendix: Glossary

This section provides definitions for various non-vendor specific acronyms used in this paper.

• .NET: Microsoft framework

• BAM: Business Activity Monitoring; provides management dashboard, business performance metrics, monitoring, reporting, and

control functionality for business processes; typically associated with BPM and considered a composite application in its own right.

• BPEL: Business Process Execution Language, previously known as BPEL4WS (BPEL for Web Services), initially defined by BEA,

IBM, and Microsoft is the XML based markup language for business process definition, is now owned by OASIS. As evident from the

name it is for orchestration of Web services only. This is typically supported by SOA vendors. Platform vendors such as Oracle and

IBM have added their own extensions to BPEL to account for human activities in processes.

• BPMN: Business Process Management Notation, for graphical modeling of business processes (not execution); this is relevant in

process modeling, analysis, and simulation tools. This is owned by OMG (Object Management Group).

• BPM: Business Process Management, a software segment within business integration market for end-to-end management of

business processes, from modeling and design to deployment and execution, to monitoring and optimization of business processes

involving both people (workflow) and systems (automation).

• BEM: Business Event Management, related to EDA. The technology for capture, correlation, processing, and management of events

in a business context. It may also be referred to as Complex Event Processing (CEP). BEM is central to ESB and BAM.

• BRMS: Busines Rule Management System, a software segment for definition, execution, and management of business rules typically

expressed in the forms of condition action. Usually an inference engine that uses forward- or backward- chaining along with

functionality for defining rules in English like languages or using wizards, conflict resolution, and versioning. BRMS is synergistic with

BPMS.

• CEP: Complex Event Processing, similar to BEM, correlation on business events and acting on them per defined business rules.

• CRM: Customer Relationship Management

• DTD: Document Type Definition, An older standard for defining XML metadata (schema) but it only contains structure information and

not data types. See XSD (XML Schema).

• EAI: Enterprise Application Integration; used for application integration vendors with proprietary systems a few years back. Now it is

used increasingly less and is subsumed by other technologies such as BPM, SOA, and composite applications.

• ECM: Enterprise Content Management, a system for managing unstructured (various document formats) and structured (in XML)

content on an enterprise scale. ECM has close ties to BPM as any process involves routing and manipulating a fair amount of

content. A process itself is a metadata that can be treated as content.

• EDA: Event-Driven Architecture, relates to ESB and CEP.

• EMS: Enterprise Management System for system management such as CA Unicenter, IBM Tivoli, HP OpenView. BAM and EMS

have good synergy. In fact some EMSs now provide BAM functionality, competing with BPM-centric BAM vendors. They have also

started to provide Web services management competing with pure-play ESB/SOA vendors.

• ERP: Enterprise Resource Planning; suite of business applications for financials, order management, etc., such as SAP and Oracle.

• ESB: Enterprise Service Bus, the key product component in an SOA suite, where various applications and systems connect to a

backbone and can post and receive messages/events from it.

• HTTP & HTTPS: Hyper-Text Transfer Protocol is the protocol used by WWW. HTTPS is Secure HTTP.

• IDE: Integrated Development Environment

• J2EE: Java 2 Enterprise Edition

• OASIS: Organization for the Advancement of Structured Information Standards), a not-for-profit, international consortium that drives

the development, convergence, and adoption of e-business standards. OASIS owns many of the important Web services and SOA

related standards such as BPEL, WS-Security, and WS-ReliableMessaging.

• OMG: Object Management Group, an open membership, not-for-profit consortium that produces and maintains computer industry

specifications for interoperable enterprise applications.



• RTE: Real-Time Enterprise, a term used by Forrester for agile enterprise where events cause changes in real-time. It relates to SOA

and EDA.

• SOA: Service-Oriented Architecture, a modern architectural concept for enterprise where functionality from various applications is

available in autonomous, loosely coupled services with well-defined interfaces. Then new applications and services can be viewed as

a composition and orchestration of these reusable services.

• SOAP: Simple Object Access Protocol, encoding format for remote invocation for sending and receiving messages.

• SCM: Supply Chain Management, business applications for managing value chain (supply and demand) in a chain of supplier-vendor.

• SMTP: Simple Mail Transfer Protocol, the underlying protocol for e-mail

• UDDI: Universal Description, Discovery, and Integration, a directory service; equivalent of yellow and white pages for Web services.

• Web services: The key building block, a reusable software component that implements a particular (business) function, with a

published interface in WSDL.

• WS-I: Web Services Interoperability Organization, an open, industry organization chartered to promote Web services interoperability

across platforms, OSs, and languages.

• WS-ReliableMessaging: An important OASIS Web services standard that is concerned with guarantee of message delivery between

Web services. It addresses message delivery requirements such as at least once, at most once, exactly once, and in order.

• WS-Security: Another important OASIS Web services and security standard that defines security functions for Web services.

• WSDL: Web Services Definition Language, the standard for defining interfaces to Web services

• XML: The base meta-language for many SOA related technologies and standards

• XPath: An expression language to select, sort, and compare data in XML documents; often used with XSLT for transformation and

mapping.

• XQuery: A query language in XML for pattern matching and manipulation

• XPDL: XML Process Definition Language is WfMC’s standard for process execution language. It explicitly supports human activities

besides system elements such as Web services. This standard is mostly backed up by BPM vendors.

• XSD: XML Schema to define and control structure and data types in XML.

Documents

FILENET P8 The Synergy Between BPM