Business process management—Part 2 The technology maze

By Laurent Lachal

IT vendors are approaching business process management (BPM) from two opposing perspectives. The first is a top-down, revolutionary approach in which BPM is seen as a new way of defining software architectures and applications. This is the "technology" view propounded by the BPM Initiative BPMI, which advocates the use of a new platform called a BPM system or BPMS.

The second is a bottom-up, evolutionary approach in which BPM is the next step in the maturity process of current software products. This is the "marketing" view adopted by most existing software vendors.

Ten years ago, object-oriented technology was similarly caught in a tug of war between technology purists—the Object Management Group—and existing software vendors selling intermediate solutions such as object-based software.

The BPMI perspective

The core argument of the BPMI camp is that, while workflow technology (either delivered as an independent product or embedded) has evolved in terms of functionality and technology, it has not evolved in terms of design. It argues that a BPMS:

• not only makes it easier for you to create and manage your business process, but also frees you from the design shackles that traditional products impose on you.

• not only redefines the way you design processes, but also the way you design software (see "The purists and the pragmatists" section of Part 1 of this series, KMWorld, March 2004).

Unfortunately, the debate remains a theoretical one because only one product currently fits the BPMI's definition of a BPMS (from a start-up vendor called Intalio, and because the technology underpinning the BPMS (standards included) is in its infancy.

Design is crucial

In the past 30 years, the core concern of software designers has evolved from focusing on transaction processing (getting data in) to business intelligence (getting data out), to where we are today: focusing on business process awareness (getting data around). Process awareness comes in two flavors:

• Processes are becoming increasingly explicit and, as such, easier to define, monitor and change.

• Software products have evolved from interacting with users from a data point of view toward a business process perspective.

The technology and functionality delivered as part of the increasing process awareness have evolved significantly in the past 10 years. However, whether delivered independently as part of a workflow product or embedded in another type of software application, the ability to define processes has remained fairly limiting. For example, current software products limit you to:

• a static chained process flow model, rather than a devolved and dynamic one. All the tasks in a process originate from a single, initiating event. The resources that the software uses and the rules that govern the transitions between tasks are all specified at design time. Very few products provide facilities that enable users to define a task or a subprocess at runtime rather than at design time. They cannot support processes that do not have a defined "process path"—that is, where transitions between tasks are devolved and determined, either by matching exit and entry conditions of tasks or broadcasting events to appropriate handlers.

• a concrete process flow model rather than a control flow one. A concrete flow model views workflow as a way to transport forms, data or documents. Tasks use the same content resources, which change state as they progress through the tasks in a process. A control flow model, in contrast, views workflow independently of the data flow between tasks. In other words, tasks in a workflow process may share information resources, but the process flow is not dependent on it. In a control flow model, responsibility for carrying out a task is handed over.

Many products have moved from system delivery ("Do this") to more flexible system offer models ("Could you please do this?" "Who has the time/skill to do this?"), but have not gone far enough in that direction. They still define a task as something done by one person at one time, using one application or resource and do not support collaborative tasks, where work is the result of real-time interaction between two or more people. The situation is made even more confusing because different types of process-aware software are designed to address different types of process—human-oriented workflow, application integration, ad hoc collaboration, business-to-business. The BPMI's vision is to address those limitations through a business process management system (BPMS).

The BPMS as defined by BPMI

A BPMS has three major parts:

• an execution engine that executes process models;

• a series of tools that support the whole process life cycle (process specification, design and discovery tools, process configuration and deployment tools, process monitoring, analysis and optimization tools, as well as specific BPMS management tools); and

• connectors that enable the BPMS to interact with the software programs required by the processes executed by the process engine.

A BPMS acts like a virtual machine, executing process models rather than software code. BPMI claims that the BPMS is to processes what a relational database management system (RDBMS) is to data, or a spreadsheet is to numerical data. It points out that a BPMS supports any process model, just as a DBMS supports any data model.

BPMS obstacles

Figure 2 highlights significant limitations of the BPMS framework and current solutions:

• The tools to support the process life cycle are immature.

• The BPMS execution engine needs to prove its quality of service (scalability, reliability and security) credentials.

• The BPMS must rely on incredibly smart connectors to interact with the software programs required by the processes executed by the BPMS process engine. That is a key challenge that will make or break the whole BPMS framework. Users will need to add or refine connectors when creating new processes that require more or new application resources.

The BPMI positions the BPMS as a platform that manages the end-to-end state of all processes across various units of the same businesses, as well as between businesses. However, so far the BPMI has not focused on the interoperability of BPM systems. Given those limitations, it is no surprise that there is only that one immature BPMS solution today, the one from Intalio, a founder of the BPMI).

When and if

It took 10 years for the RDBMS to become pervasive. It will similarly take years for people to first understand and then implement a BPMS. When, and if, credible BPM systems become available, there will be further delay before a new industry emerges to develop tools and applications capable of exploiting a BPMS—just as there was a similar delay following the availability of RDBMS solutions.

Over the next five years, most large enterprise application and software infrastructure vendors will start to offer their own BPMS. Those vendors, dependent on their origins and existing solutions—process-centric workflow, information management, software infrastructure, enterprise applications—will approach it from a different perspective. Even if the technology hurdles are overcome, more generic hurdles will remain. The market will have to grapple with the implications of this new type of software platform: It will not only lead to the redesign of software products, but also to the redesign of IT service providers and their offerings. The BPMS could be the stimulus for a new generation of service providers—such as process service providers (PSP) and process improvement services providers (PISP).

Users will have to reorganize themselves to effectively exploit that new type of software platform. There will be a particularly steep BPMS learning curve, given how companies have struggled to exploit current process-aware software products. Every employee, not just management, can potentially be directly involved with the BPMS and, if granted permission, make changes to processes that will immediately be executed. The BPMS will become a focus for process-oriented teams (supply chain, customer support), as opposed to teams from different stovepipe disciplines (IT, procurement, business operations, finance and customer relationships). The BPMS will also redefine how business and IT managers interact with each other.

Current software products are limited in the type of process they enable you to design. However, coupled with a proactive process portfolio management strategy and the creation of an enterprise model (as advocated in Part 1 of this series), they can certainly go a long way to help you to understand and manage your business processes. Making the best use of some of the current software products within the proper strategic framework will also position you well to make the best of the next generation of BPM solutions.

Standards

The BPM Initiative (BPMI, bpmi.org) is responsible for the definition of standards for business process modeling, deployment and execution. A BPM system (BPMS) can only execute processes defined using those standards. Just as SQL was critical for the success of the relational database management system (RDBMS), so standards are key to the ultimate adoption of BPMS. The key standards are:

• Business Process Modeling Language (BPML)—a meta-language for describing business processes analogous to XML as a meta-language for describing business data. It is not Web service-specific. However, the BPMI has aligned it with the Web Service Choreography Interface (WSCI, pronounced "whiskey"), an emerging protocol for the choreography of Web services-based processes.

• Business Process Modeling Notation (BPMN)—to create a graphical representation of BPML models.

Those standards are either immature (like BPML and BPMN) or not published yet (as with BPQL), and they are vying with other standards to become the standard for BPM. Figure 3 summarizes the main standards in the BPM area (there are others), each with its specific perspective:

• Business Process Execution Language for Web Services (BPEL4WS) or BPEL (pronounced "bee pell") is supported by Microsoft, IBM, BEA, SAP and Siebel, as well as smaller vendors, and focuses on Web services-based processes. It deals with both language and protocol issues.

• Unified Modeling Language (UML) and Business Process Definition meta-model (BPDM) is supported by the Object Management Group, and looks at BPM from a software component development point of view.

• XML Process Definition Language (XPDL) is supported by the Workflow Management Coalition (WfMC, wfmc.org), and looks at BPM from a workflow point of view.

• E-Business XML (ebXML) looks at BPM from a B2B integration point of view. Some vendors support more than one standard. For example, IBM plays a role in all of these standards initiatives. SAP is or has been involved in most of them. BEA participated in both BPEL and WSCI.

BPEL, which competes with both BPML and WSCI, is likely to win out as the BPM standard by virtue of the market strength of IBM and Microsoft. Fortunately, the BPMI appears to have recognized that, and is likely to support it.

Laurent Lachal is a senior analyst specializing in business process management at Ovum, e-mail lal@ovum.com.