Carnets de bord

Table of Contents Introduction What is a business process anyways? Why business process management systems? why today? Key technologies for BPMS BPMS Architecture

---

Introduction

Well, here is an attempt to bring together ebXML, Web Services, PMLs (BPML, BPEL, WS-CDL...) and define their respective roles and responsibilities, while showing how they fit in an overall IT infrastructure.

So we start with the basics and the p-calculus theory. For those of you who are not familiar with it and remember a few lectures of your college math classes, I really recommend reading about it. The best source is the book from the inventor of the theory: Robin Milner. You can also read this section which explains the differences between State, Actions and Interactions in the context of finite state machine.

We then move on an review the current state of Web Service specifications and explain why web services are the foundations of all three modern Process Markup Languages (BPML, XLANG and WSFL).

You should be ready now to to take a look at the architecture of Business Process Management systems. We will then move on to the analysis of the Process Markup Languages.

What is a business process anyway?

Everything that looks like a series of steps tends to be labelled a business process. Here is a simple taxonomy of "business processes". For the purpose of this discussion we will distinguish five concepts, all of which are referenced in the literature as "business processes": 

• Enterprise business processes 
• Executable business processes 
• ebXML business processes (a.k.a. collaborations) 
• Business process activities 
• Workflows

An Enterprise Business Process (eBP) is the description of steps needed to carry out a business activity regardless of the systems involved. They provide a high level view of the steps involved and can be used to model, benchmark and document existing or future designs. Enterprise business processes are actually free to span multiple corporations because of their nature which is not bounded to systems. An example would be describing all the steps that are required to happen for a pair of shoes to be manufactured in Asia and appear at your favourite store at the mall.

An Executable Business Process (xBP or Business Process for short) is a kind of eBPs which lifecyle is controlled by one or a combination of systems. We will call these systems: business process management systems (BPMS). It is limited to run within a single corporation. One of the important characteristics of an eBP or xBP is that it is long running. Its execution is not limited to minutes or hours like the session of a web-based application, it rather spans days, months, or years. An xBP relies on specific interactions between users, systems, and business partners which it ties together. This system provides all the facilities and services necessary for design and execution, and mediates the integration with its environment. As we will see in the later sections of this chapter, a BPML, XLANG or WSFL business process is an XBP.

An ebXML Business Process (Collaboration) is a business collaboration specification which can be used to specify how two concurrent executable business processes interact at the business level.

A Business Process Activity (Task) represents a short-lived interaction between users or, in certain cases, systems. BPas are often managed by a Session Bean in a J2EE based application. A BPa can be viewed as one step in an executable business process. A typical example is a user browsing a catalogue and filling a shopping cart. Once the user is finished, he or she pushes the checkout button, which in turn completes the activity. The proper information is passed to a business process management system as part of a completion message. Overall, the concept of long running executable business processes is not part of the J2EE architecture - this architecture was solely designed to provide the services to build standalone web-based OLTP applications. Typically, in the current J2EE model, a developer has to hard code the long running state management.

Lastly, some people are talking about Workflow, or strangely enough they use the term Business Process Workflow. We can often associate workflow to "automated document management" which requires reviews and approvals: for instance the review of a proposal or a contract by a large number of people. The engine in charge of this task does not know much about the documents themselves and is merely routing them through different people while keeping an audit trail. There is little or no integration with enterprise systems, let alone with other partners.

Business Process or Workflow?

Ultimus provides an excellent definition of workflow "Any task performed in series or in parallel by two or more members of a workgroup to reach a common goal." Note the words with emphasis: Any Task: Which implies that workflow refers to a very wide range of business related activities. Series or in Parallel: Which implies that steps in the task may be performed one after the other, or simultaneously by different individuals, or a combination of the two. Two or More Members: Which implies that if only one person performs a task it is not workflow. As the workflow name suggests, a task is workflow if it "flows" from one individual to another. Common Goal: Individuals participating in workflow must be working towards a common goal. If they are working on independent projects, that does not constitute workflow.

 

Why Business Process Managements Systems? Why Today?

Since the Internet revolution enterprises have opened their core functions to customers, business partners, suppliers and financial institutions. 

In doing so, they have created a maze of intranet, extranets, B2B integrations, using various technologies ranging from EAI solutions, to Portals, B2B integrations. Business Process Management Systems are the ultimate evolution of this quest for better interactions between the enterprise and its environment. A BPMS is a strategic platform that manages the relationships at the enterprise level, regardless of the geography, organizational structure and IT. 

The major barrier to a B2B implementation is not necessarily technology but rather cost. If you spend $1000 (hardware, software licenses, labor, maintenance, support…) on each of the 1000 business partners, you have already spent $1,000,000. The cost of such a project could easily run into several hundred million dollars for a given business community or industry. Even if this cost is not fully supported by a single corporation, the higher it is, the less likely it will be that the overall project will be successful, because partners will delay their decision to implement an expensive infrastructure. The complexity and technical risks will also be directly related to the cost of implementation.

Problem solved : How do I enable my company to let its customers, partners and suppliers interact with its core functions (Sales, Production, Design and Marketing) in a secure environment?

Value proposition: bring rationalization and agility across the dozens if not hundreds of business processes a global corporation need to support and which touches an increasing number of enterprise information systems (EIS).

Measure of success: how easy it is to adapt a business process to a changing economic environment? can I manage personalized relationships with my customers, partners and suppliers? 

Key technologies for BPMS

The Internet has changed dramatically the technical infrastructure of most IT departments, sometimes bringing extreme challenges (security) while enabling customers, suppliers and employees to reach the information they need and transact at will with core enterprise systems. These capabilities have also created an environment where enterprise systems are solicited by thousands of events daily which require near real-time processing.

Business Process Management Systems are the key infrastructure for routing all these events to the appropriate processing end point within the enterprise or onto a business partner system. There are four key technologies which make BPMS architecture more efficient:

• XML
• B2B middleware
• Enterprise Application Integration 
• Web Services

XML has freed BPMS from the intricacies of the interaction with data sources. In the past, most workflow engine that was developed had a collection of libraries to fetch or update data from a large variety of data sources. XML is bringing data into the data flow as "documents" which can be handled generically by the BPMS. In addition, business rules (decisions, guarded transitions, ...) can be written in standard XPATH predicates, sometimes even in a fashion independent of the overall XML document structure. XML combine with XSLT (and often CSS) can also bring the data flow to the user's desktop such that engineering change order or the purchase of your laptop can be approved.

B2B Middleware based on standards such as ebXML is also providing a homogeneous way to connect securely business process management systems to the outside world. BPMS can take advantage of Trading Partner Agreements to route messages dynamically to the correct business partner system. Again, without such a common infrastructure BPMS vendors would spend a good deal of their resources to reconcile different protocols together.

Enterprise Application Integration is actually the oldest of the three technologies since major frameworks appeared in the mid 1990s with New Era Of Network (NEON), Mercator, or Oberon Software ... Most of these players have been acquired while new players such as WebMethods or CrossWorlds have brought this technology to a level of maturity which also provides a homogeneous environment  which enables a BPMS to interact with virtually any enterprise and legacy systems.

Web Services are the latest wave of technology which aims at standardizing the interactions between systems. It is the direct heir of the 1990s middleware technologies and provide a common abstraction to both web-based applications, component based systems or any legacy system.

Because the interfaces to data sources, enterprise systems and business partners have been "standardized", the BPMS technology can start developing and act as a coordinator of the information flow, transaction flow and value flow across and beyond the enterprise.

 

BPMS Architecture

The BPMS architecture has to be optimized to connect to the largest number of business partners, employees and enterprise systems.

The BPMS acts as a bridge between three interfaces. First between an Application Service Interface (ASI) and the Business Service Interface (BSI). The ASI wraps all enterprise, legacy, and e-business applications into a set of Web Services. The BSI manages the interactions between executable business processes and the business partners. 

The third interface is "browser-based document exchange" for users like you and me. This is the paradox of automation: we can only automate if we are guaranteed that exceptions will be properly raised and resolved with the appropriate person or business partner employee approving a document, or filling out missing information.

The architecture should also support legacy formats such as EDI or flat files. It is probably better to optimize the design of the BPMS  for XML since most of the messages will use this format. Necessary transformations should be used to go from and to other data formats, as well as from an XML format to another one (RosettaNet to OAGIS...)

Most products currently available on the market follow closely or loosely the model we just presented.

Resources

BPM by Srihari Govindarajan