verner - bpm the promise and the challenge

8/4/2019 Verner - BPM the Promise and the Challenge

1/9

82 March 2004 QUEUE rants: [email protected]

s all about closing the looprom conception to execution and back.


2/9

QUEUE March 2004 83more queue: www.acmqueue.com

Over the last decade, businesses and gov-

ernments have been giving increasing

attention to business processesto their

description, automation, and manage-

ment. This interest grows out of the need

to streamline business operations, consoli-

date organizations, and save costs, reecting the fact that

theprocess is the basic unit of business value within an

organization.

The design and automation of business processes even

warrants its own eld of study, known as BPM (business

process management). A quote fromIBM Systems Journal

sums it up nicely: BPM technology provides not only the

tools and infrastructure to dene, simulate, and analyze

business process models, but also the tools to implement

business processes in such a way that the execution of the

resulting software artifacts can be managed from a busi-

ness process perspective.1

The level of interest and the concomitant market-

ing hyperbole around BPM has reached a crescendo. As

an example, Gartner announced that BPM wins the

Triple Crown of saving money, saving time, and adding

value. Is this promise being fullled? BPM does have the

potential to deliver signicant value, but there are miss-

ing elements that limit its effectiveness. Although BPM

technologies are becoming more mature, many software

developers and business analysts still nd themselves ask-

ing the basics: What is it? And why should I care?

This article provides a high-level overview of BPM

and where it is today and touches on some of the core

technologies and standards. The focus is on four specic

challenges facing BPM, which are aligned with the four

phases of the application development life cycle:2

Discoveryrefers to having an understanding about the

current environment.

Design involves the analysis of the current processes and

the denition of future state processes.

In the developmentphase the future state is implemented

in technology, which may involve process automation

using a BPMS (business process management system).

The new processes are put into production in the deploy-

mentphase.

BPMThe Promise

and theChallenge

LAURY VERNER, PROACTIVITY


3/9


In each phase we explain the problem and explore its

business and technical consequences.

HOW DID WE GET HERE?

Business process management is an old discipline

that allows you to model the organizational structure,dene the business processes, and show the interac-

tions between them. It is traditionally taught in business

schools and is put into practice with varying degrees of

success. In the 1990s the work of Michael Hammer and

James Champy,3 authors of the widely readReengineering

the Corporation, focused attention on business processes,

both as a root cause of inefciency and as the source of

potential competitive advantage. They advised a deep

and radical redesign of the business to root out waste and

increase the focus on the customer. That was 10 years

ago. What is different today is the novel use of comput-

ing technology to drive the analysis and automation of

business processes.

InBeyond Engineering, a follow-up toReengineering the

Corporation, Hammer denes a business process as a

complete end-to-end set of activities that together create

value for the customer.4 The notion of customer in

this context refers to the recipient of the value provided,

not necessarily a paying customer in a commercial trans-

action.

Innovations in technology such as XML, Web services,

component-based development, and message-oriented

middleware have fueled the current interest in BPM. Ven-

dors have developed BPMSs that provide the ne-grained

integration of systems and data needed to automate

business processes. The BPMS links people and systems,

manages information access and transformation, handles

exceptions, and orchestrates the ow of the process.

Organizations are looking to BPM to help solve the

following kinds of problems:

A computer vendor, to be competitive, needs to cut

its costs for fullling customer orders for PCs by 70

percent.

A pharmaceutical company seeks to extend the patent

life of its drugs by bringing new products to market one

month earlier.

A government agency forced to reduce staff by 30 per-

cent must nd a way to consolidate and streamline its

unemployment benets services.

Company executives, personally accountable under theSarbanes-Oxley Act of 2002 for their companys nan-

cial statements, need to understand and control the

processes that result in these statements.

CHALLENGE 1: DISCOVERYIn order to improve business processes, you must begin

at the beginning. Typically, business analysts, needing to

discover the current state of things, try to visually repre-

sent the various processes of the business. The approach

taken by many BPM products fails to address this chal-

lenge adequately. They employ a drawing metaphor in

which an analyst or developer sketches the process using

a palette of standard icons. This assumes the existing

process is known in advance. Most large organizations,

however, simply do not knowtheir end-to-end processes

accurately or in detail. Their process knowledge is tacit

and decentralizednot explicit and centralized.

How can you discover how a business operates? Classi-

cal manufacturing processes have been analyzed exten-

sively in quantitative and qualitative terms. Discovering

general business processes is somewhat less straightfor-

ward. You can adopt either a top-down or bottom-up

approach. The top-down discovery approach typically

begins with the organization chart. It lists the responsibil-

ities of each department in the organization and identies

the high-level processes that support these responsibili-

ties. These processes are then decomposed into lower-

level processes, which are decomposed further, until the

lowest level is reached. The advantage of this approach

is that it provides a broad, organizational perspective. Its

disadvantage is a lack of detail and a questionable degree

of accuracy.

The bottom-up approach begins by interviewing

employees about the day-to-day activities they perform

BPMThe Promise

and theChallenge


4/9


and attempts to integrate this local information into

coherent end-to-end processes. This approach can be

extremely accurate but you can easily get lost in the

details, failing to see the forest for the trees. Some hybridtop-down/bottom-up approaches seek to achieve the

advantages of both methods.

Since no two organizations are exactly alike in how

they operate, different discovery methods may be appro-

priate in different businesses. Further, a single capture of

business processes is likely to be woefully inadequate. As

is so often the case, later discoveries inform earlier ones,

and an iterative discovery methodology that continu-

ally enhances and updates the processes may yield better

results. Regardless of the methodology followed, there is

of course the key requirement that senior management

support and drive the business-process discovery. Withoutthis support, the chance of success is minimal.

Business Consequences. As awareness of the impor-

tance of business processes grows, many companies

are attempting to capture their current-state business

processes. They form workshops of business users, sketch

the processes, and try to achieve consensus within the

team. Unfortunately, they have no way to ensure the

accuracy or completeness of the resulting diagrams.

Often the underlying complexity of existing business

processes is oversimplied by such workshops. Much of

the important meta-data about the processes, such as

cost, cycle time, and information ow, cannot be easily t

into Visio diagrams. Moreover, the information contained

in the processes cannot be analyzed effectively in these

diagrams.

Technical Consequences. Accurate capture of current

processes is a prerequisite for dening

the structure and rules of the desired

future process. Without this level of

understanding, the developer may

produce a suboptimal solution with

the BPMS tool or, worse, a solution to

the wrong problem. BPMS tools were

designed to automate processes, not to

analyze business. The process automa-

tion implemented using a BPMS may

therefore fall short of the true goals of

the business. Why not ask the busi-

ness analysts to use the BPMS prod-

ucts to discover and analyze business

processes? This would seem to solve

this problem. Unfortunately, most

BPMS products have been designed for

developers, not for business analysts.

They provide few if any capabilities for process discovery,

dening meta-data, simulation, or analyzing process costs

or cycle times.

CHALLENGE2: DESIGNThe ultimate purpose of BPM is to improve and opti-

mize the operations of an organization. Thus, its scope

necessarily comprises not a single process but all processes

across the organization. Unfortunately, BPMS products

are generally designed to work on one process at a time.

The developer draws the process, adds implementation

constructs, and then executes the process. There is no

way in these tools to look across multiple processes,

examine process interconnections, make comparisons, or

perform analysis.

It would be helpful to have a process laboratory ofsorts, where business analysts could collaborate, explor-

ing the process space, testing ideas, measuring, analyz-

ing, and comparing processes, and generally performing

business thought experiments. This laboratory would

give analysts the tools to design new processes, view the

processes from multiple points of view, extract analytical

reports across processes, generate system requirements,

and perform simulation and what if experiments. It

would allow them to create centralized reusable processes

that could be invoked by processes in different operating

units.

Obviously, one key element in such a laboratory is a

language to express ideas. This process language would

be used to dene the basic entities of business processes

(processes, participants, activities, links, etc.) and the

rules for their operation and interaction. A standard pro-

cess language would allow customers

to use products from different vendors

for dening and implementing busi-

ness processes. Processes dened in

one product could be executed on

another product.

Over the past three years, various

groups have made numerous attempts

to dene standards for Web services

and business processes. The relevant

organizations are the Workow Man-

agement Coalition (WfMC), Business

Process Management Initiative (BPMI),

World Wide Web Consortium (W3C),

and OASIS.5

WfMC promotes the use of work-

ow by helping to establish standards

for terminology, interoperability, and

What isdifferent today isthe novel use of

computing technologyto drive the analysis

and automation of

business processes.


5/9


connectivity between workow products. It has created

xpdl, an XML-based denition for business processes.

The mission of BPMI is to promote and develop busi-

ness process management by establishing standards for

process design, deployment, execution, control, and opti-

mization. BPMI has developed three standards: BusinessProcessing Modeling Language, Business Process Model-

ing Notation, and Business Process Query Language.

Founded by Tim Berners-Lee, W3C has published

the key standards for XML, HTTP, HTML, SOAP (Simple

Object Access Protocol), and Web services. All W3C stan-

dards must be royalty free.

OASIS (Organization for the Advancement of Struc-

tured Information Standards) is a not-for-prot, global

consortium that drives the development, convergence,

and adoption of e-business standards. OASIS has dened

standards for e-business applications (ebXML) and is

working on other high-level Web services standards. In

contrast to the W3C, standards published by OASIS may

have royalties attached to them.

An important XML-based language for dening

business processes is the Business Process Execution

Language for Web Services (BPEL4WS or simply BPEL6),

a language created by Microsoft, IBM, and BEA Systems.

It grew out of work done by Microsoft (XLANG) and by

IBM (Web Services Flow Language). Microsofts approach

was inspired by structured programming, whereas IBMs

approach viewed a process as a directed graph. BPEL

attempts to integrate these two viewpoints. The OASIS

Web Services Business Process Execution Language

Technical Committee is charted to continue work on

the business process language originally published in

August 2002.

The underlying assumption behind the BPEL specica-

tion is that business processes will be composed of a series

of interacting Web services. Since WSDL (Web Services

Description Language) is the natural language for describ-ing Web services, the BPEL designers chose to make BPEL

an extension of WSDL. Each activity in a BPEL process

is implemented by a Web service, which is dened by its

port types, operations, and messages.

In the conceptual scheme of BPEL, a business process

is composed of a central process engine (see gure 1) that

interacts with a set of business partners. Each Web-service

operation is performed either by one of the partners or by

the central process engine itself. The process engine com-

municates with its partners by exchanging messages.

The process engine and partner send messages across

a communications channel called a service link (see

gure 2). To make this more concrete, let us consider a

travel agency interacting with an airline. The service link

is a bilateral contract between the travel agency process

and the airline that denes the services each offers to the

other.

The process and the partner play different roles across

the service link. The process, in its role, exposes a WSDL

port typethat is, a set of operations that it agrees to

offer. Similarly, the partner, in its role, exposes another

set of operations. In our example, when the travel agency

process invokes the airlines ticket-order operation, it is

actually using a service link, which we have called the

buyerLink. The role of the travel agency process in

buyerLink is ticket requester

and its port type is itiner-

ary. The role of the airline

partner is ticket service and

its port type is ticket order.

Having dened this

conceptual framework for

partner interaction, BPEL

goes on to specify the usual

BPMThe Promise

and theChallenge

processengine message partnermessagepartner


6/9


building blocks of processes: activities, ows, links, data

containers, and assignment operations. These are dened

in terms of their XML structure, but without a graphical

model for representing them. The inuence of Microsoftand IBM is apparent in these denitions. For example, if

you want to specify that activity 1 must precede activ-

ity 2, you have two ways to do so. One way is to use the

structured activity called sequence. The other way is

to connect these activities through a link within a ow.

The rst approach is inherited from Microsofts XLANG,

and the second is inherited from IBMs WSDL. The BPEL

specication provides no hints as to when to use one

technique or the other.

BPEL also addresses technical constructs required for

proper execution of the business process. These include

correlation, fault handling, and compensation. Correla-tion is the technique used to create associations between

process instances by using the data elds as identiers.

For example, a eld order number might be used to

correlate a purchase order and a purchase-order acknowl-

edgment. Fault handling and compensation specify the

procedures to be followed when an error occurs in the

process. For long-running processes, the idea is to undo

a complex series of activities with a compensating series

of activities.

In BPEL, each process is an assemblage of Web services,

but the process is itself a large-scale Web service. This

fractal-like approach enables unlimited composition and

decomposition of Web services.

BPEL is a signicant achievement but has several weak-

nesses that limit its widespread adoption:

Addresses only processes composed exclusively of Web

services.

Has no graphical rendering. To date, no available prod-

ucts generate process graphics from a BPEL document or

vice versa.

Does not include a framework for performing top-down

designthat is, for creating a process in a series of layers

with successive renement.

Provides no capabilities for process analysis.

Is a vendor-driven process denitions language that has

not yet been reected in a royalty-free standard pub-

lished by a recognized standards group.

The major competitor to BPEL as a process language

based on Web services is BPML (Business Process Manage-

ment Language). Both BPEL and BPML are ultimately

based on the calculus, but the Business Process Man-

agement Initiative introduced BPML two years earlier

than BPEL. BPEL has actually incorporated many BPML

concepts and, with the support of Microsoft and IBM,

it has the advantage of industry momentum. Microsoft,

IBM, and BEA Systems will likely introduce BPEL in theirproducts over the next year, perhaps with some propri-

etary language extensions and some tools to aid in

process design.

Business Consequences. The goal is to translate the

process information gathered in discovery into a standard

process language, such as BPEL. But business analysts

cant use BPEL, at least not in its current form. Given a

BPEL process denition, you will nd it nearly impossible

to disentangle the business logic from the details of the

implementation. The business semantics are obscured

by the technical details required for execution. What is

lacking is a way to layer BPEL, to lter out such technical

constructs as fault handling, correlation, and transaction

management. It should be possible for a business analyst

to use a process language to design the business logic.

Once the business logic is mapped out, a developer can

insert the technical constructs.

Business analysts generally prefer a visual way to

design processes. They are intimidated by code, which

tends to obscure the business issues. Also, nondevelopers

need to see processes from multiple perspectives, to deter-

mine inter-process dependencies, and to extract system

requirements from processes. Business analysts would

also likely benet from a way to design processes from

the top-down, beginning with high-level processes and

rening them to low-level processes. This lies outside the

scope of BPEL. Because BPEL has no graphical rendering,

the business analyst would have to code XML. This is not

likely to happen.

Technical Consequences. In many cases the business

analysts will design the business process using an analysis

tool. Once this is done, how will the process then be

automated? It would be desirable to export the process to

the BPMS for execution, perhaps using BPEL as the lingua

process airline

itineraryport type

icket orderport type


7/9


franca. If BPEL is not used by the business process analysis

tool as well as by the BPMS, then a custom mapping will

be required to translate between the XML dialects of the

two products.

In its current form, BPEL will be of limited use since

it is designed for processes that are implemented usingWeb services. It is not usable for legacy processes that

comprise package applications, custom applications, or

manual activities.7 This excludes 95 percent of all existing

business processes.

A key goal of business-process design is to dene and

communicate requirements. For example, suppose a new

system will be used in multiple processes, supporting dif-

ferent users and systems performing different functions.

Ideally, the business processes are dened in such a way

that the functional requirements can simply be extracted

from the process denitions. If our new system performs

25 activities across 17 processes, then these activities can

be summarized by an appropriate query. This procedure

is precisely analogous to extracting data from a relational

database. Unfortunately, there is currently no searchable

knowledge base of BPEL processes. Moreover, since BPEL

has no notion of participant or actor to identify the

proposed system, it will not be able to support this impor-

tant goal of the process laboratory.

CHALLENGE 3: DEVELOPMENTA successful development project is the result of many

favorable conditions, one of the most important being

close collaboration between business analysts, who dene

the needs of the business, and developers, who imple-

ment systems that meet these needs. Business analysts

and technical developers, however, are driven by different

goals, speak different languages, and tend to work at dif-

ferent levels of precision. In the domain of BPM this gap is

manifested by automated business processes whose execu-

tion does not match the original business requirements.

Business analysts typically communicate business

needs in the form of requirements documents to the

developers, who may interpret the needs rather differ-

ently. Using a BPMS tool, the developers implement the

automated solution as they understand it. Why not have

the business analysts dene the business process using the

BPMS tools? This is not realistic since BPMS products are

generally intended for use by developers, not by business

analysts. They enable developers to create technical con-structs, not business requirements. Tools based on UML

(Unied Modeling Language) are sometimes suggested

as an alternative. UML is well suited for developers who

need to design class diagrams and lay out the interactions

between method calls. The UML suite of diagrams is,

however, not so well suited for business analysts working

with business processes.

Business Consequences. The business consequences

of the gap between business analysts and developers are

increased risk of failure and longer lead times for develop-

ment. In its research into the success rate of application

development projects, the Standish Group discovered

that most software development projects are cancelled

before they are completed.8 It also found that fewer than

20 percent of projects are completed on time and on

budget. Of those projects that do deliver on time and

budget, half fail to deliver the projected functionality. The

Standish Group notes that a key cause of such failures is

the lack of clarity in capturing and communicating user

requirements.

Technical Consequences. The classical requirements

document leaves considerable room for interpretation.

It rarely provides the IT level of precision needed by

developers, who need to know each activity that must be

performed by the system, the step-by-step control logic of

the enveloping business process, the specic data required

at each step of the process, and the business rules that

govern changes to the data. This lack of precision may

lead to misunderstandings between the analyst and the

development team. Software misses the mark, making

scrap and rework inevitable. Redening requirements,

redesigning, and recoding midstream are expensive and

time-consuming.

What is missing is a seamless way to integrate design

BPMThe Promise

and theChallenge


8/9


and development. Business analysts should create process

designs at the business level within their process labora-

tory and then export these designs in XML form to the

BPMS. Developers will then rene the design, adding the

technical constructs needed for implementation. This

eliminates any ambiguity about the requirements andbusiness need.

CHALLENGE 4: DEPLOYMENTThe whole point of automating business processes is to

improve operationsin cost, time, or quality. Once a

process has been developed and deployed, how can we

know if it is meeting the intended goals? We know how

to instrument IT systems and monitor them with a high

degree of precision. These statistics, however, do not

generally provide a business-process context around this

information. The challenge is to aggregate and present

execution data at the business-process level. Gartner

coined the term business activity monitoring(BAM) for this

capability. It denes BAM as providing realtime access to

critical business performance indicators to improve the

speed and effectiveness of business operations.9

Business Consequences. Without BAM, operational

managers have no way of determining whether the

processes for which they are responsible are meeting their

objectives. For example, they will not be aware that the

cost of the order fulllment process in the Cincinnatiregion has increased 20 percent above average, or that the

time required for handling new benets claims declined

by 10 percent in the second quarter, or that the outage

optimization process for steam turbine generators is in

trouble. Lacking this information, executives have no way

to determine which action to take. A way to aggregate

execution statistics in process contextwould help the busi-

ness manager better manage these types of exceptions.

Over the past year, several companies have developed

BAM products, but in many cases they are discrete event

monitors that lack overall process context. To achieve

true process context, you must link individual activities

into a process to provide information on what is done in

that process and by whom. For example, it is necessary to

evaluate the cost of each process instance. Moreover, it is

necessary to aggregate process instance information based

on various criteria. For example, you can group process

instances by geography, customer, or organization. Finally

you need to chain processes that logically belong

together, such as an order process and an invoice process.

All this information should be summarized and presented

on an executive dashboard on the enterprise portal.

Technical Consequences.At some level, most com-

panies recognize the importance of BAM but have no

effective way to collect, aggregate, and analyze execution

statistics. Often it is done in an ad hoc manner, in which

reports from legacy systems are combined into a data

warehouse from which summary reports can be gener-

ated. It is possible to determine quite precisely the utiliza-

tion of each disk drive, server, and network component

in the IT environment. From such statistics, however,

you will not know which resources need to be expanded,

consolidated, or upgraded to support the business objec-

tives. For example, you simply may not know whether or

BPMThe Promise

and theChallenge

analysis

execut on

discovery design


9/9


not increasing the capacity of a specic disk will affect the

order-fulllment-cycle time.

With BAM, we come full cycle. The results of process

monitoring will enable the rediscovery and redesign ofbusiness processes. Executives will know about hotspots

that demand their immediate attention. In the longer

term, the execution will keep pace with the business

needs and the process designs. Figure 3 summarizes this

life-cycle concept.

CONCLUSION

Any enterprisecorporation, government, or nonprot

organizationcan be viewed as the sum of its business

processes. Each process delivers value to customers,

suppliers, employees, or other stakeholders. BPM, the dis-

cipline for enabling and automating business processes,is in a period of rapid growth and will fundamentally

change the way computing power is applied in organiza-

tions. Whereas BPM has already delivered considerable

value in many companies, the components of the full

BPM solution are still evolving and are the subject of

ongoing research and development. One noteworthy

advance has been BPEL, an XML-based language for

describing business processes composed of Web services.

This article has focused on four immediate challenges:

1. Process discovery is the beginning of any BPM solution

and is necessary to ensure that the solution matches

the real business needs.

2. Business analysts lack a process laboratory in which to

design, analyze, and simulate business processes. Pro-

cess languages, such as BPEL, while key elements in a

process laboratory, need to be enhanced with graphical

capabilities that link them with process discovery.

3. Integration is missing between the tools used for busi-

ness process design and the tools used for execution.

BPEL may play a key role in this integration.

4. BPMs generate valuable performance statistics from

executing business processes. Businesses need to

monitor these execution statistics, organize them into

their process context, and present them in the form of

alarms, reports, and executive dashboards.

Weve made signicant progress in BPM over the

past three years. We expect many of these challenges to

be addressed in the next three years. Others may prove

less tractable and will take a little longer to solve. Once

this happens, for the rst time we will have a complete,

closed-loop approach to business processes: from concep-

tion to execution and back. This will give executives the

ability to design their business processes, automate them,

and determine quantitatively how well they are doing

against plan. With this information, they can then rede-

sign or optimize the processes.

Gradually, the technologies and techniques described

here will change the way businesses and governmen-tal agencies apply technology. In the words of Howard

Smith, Third-wave business process management

methods and systems will utterly transform the way

companies conceive, build, and operate automated

systems.10 Q

REFERENCES

1. Leyman, F., Roller, D., and Schmidt, M.-T. Web services

and business process management.IBM Systems Journal

41, 2 (2002) 198.

2. CSCs Catalyst 4D development methodology.

3. Hammer, M., and Champy, J.Reengineering the Corpora-tion. New York: HarperCollins, 1993.

4. Hammer, M.Beyond Reengineering. New York: Harper-

Business, 1996.

5. Workow Management Coalition: see http://

www.wfmc.org; Business Process Management Ini-

tiative: see http://www.bpmi.org; World Wide Web

Consortium: see http://www.w3.org; OASIS: see http:

//www.oasis-open.org.

6. Business Process Execution Language for Web Ser-

vices, Version 1.0. IBM: see http://www.ibm.com/

developerworks/library/ws-bpel/.

7. Unless they have been previously wrapped as Web

services.

8. The Standish Group. The Chaos Report (1994), http:

//www.standishgroup.com/sample_research/chaos_

1994_1.php.

9. McCoy, D. Business activity monitoring (BAM)deeper

meanings,Business Integration Journal (Aug. 2003), http:

//www.bijonline.com/Article.asp?ArticleID=755.

10. Smith, H., and Fingar, P.Business Process Management:

The Third Wave. Tampa: Meghan-Kiffer Press, 2002.

LOVE IT, HATE IT? LET US [email protected] or www.acmqueue.com/forums

LAURY VERNER ([email protected]) is chief

technology ofcer of ProActivity, a Boston-based

company that develops software for business process

analysis and design. Prior to that, Verner was a partner at

Computer Sciences Corporation Consulting, specializing

in application architecture. Verner has a Ph.D. from the

Johns Hopkins University and a B.A. from the University

of Pennsylvania.

2004 ACM 1542-7730/04/0200 $5.00
http://www.wfmc.org/http://www.wfmc.org/http://www.bpmi.org/http://www.w3.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.ibm.com/developerworks/library/ws-bpel/http://www.ibm.com/developerworks/library/ws-bpel/http://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.bijonline.com/Article.asp?ArticleID=755http://www.bijonline.com/Article.asp?ArticleID=755http://www.bijonline.com/Article.asp?ArticleID=755http://www.bijonline.com/Article.asp?ArticleID=755http://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.standishgroup.com/sample_research/chaos_1994_1.phphttp://www.ibm.com/developerworks/library/ws-bpel/http://www.ibm.com/developerworks/library/ws-bpel/http://www.oasis-open.org/http://www.oasis-open.org/http://www.w3.org/http://www.bpmi.org/http://www.wfmc.org/http://www.wfmc.org/

verner - bpm the promise and the challenge

Documents