18 1092-3063/99/$10.00 © 1999 IEEE IEEE Concurrency

Processes Driving theNetworked Economy

together to deliver products and solutionsin the global marketplace. The trends forvirtual corporations and e-commerce—along with increased economic global net-working—are real and will accelerate.Using the Internet and the Web as the pri-mary communications, interoperability,and integration platform, information sys-tems will play an increasingly critical rolein providing a competitive edge for orga-nizations in the networked economy. Sofar, most of the attention in InformationSystems has gone to data. We believe thatthis attention will increasingly shift toinformation and knowledge on one handand processes on the other. The first dealswith service and product, the second dealswith how to effectively support or renderit. This article focuses on the second issue.

An organizational, or business, processis any multistep activity that supports theorganization’s mission, such as providing aservice or manufacturing a product. To-day, workflow technology is the mostimportant software technology that sup-ports and automates organizational pro-cesses. The research and technologies thatmake up workflow-process management

represent tremendous diversity, due in partto the breadth, complexity, and multidis-ciplinary nature of the problems thatworkflow-process management addresses.1Consequently, compared to contemporarytechnologies such as messaging, databasemanagement, and applications servers, itis harder to provide comprehensive cover-age for all the issues facing workflow—alimitation this article admits to—and tobuild technology that enhances it.

We see process as an organic part ofdoing business in the future—that is,although processes will chiefly differenti-ate between the competitive forces in thenetworked economy, they will be deeplyintegrated into business itself. Processeswill be critical components of almost alltypes of systems supporting enterprise-level and business-critical activities. Unlikedatabase-management systems (an impor-tant category of tools that will continue tobe standalone products on which to buildapplications), workflow technology willnot be as significant a market force as aseparate category of software tools. ForWeb sites with further information, pleasesee the related sidebar.

This article proposes

that an organic work-

flow-process technolo-

gy will power the

evolution of informa-

tion system architec-

tures. The authors

outline three likely

stages of architectural

evolution in the context

of a networked econ-

omy and discuss critical

gaps in the current

technology with respect

to their envisioned

future.

Workflow

Speed and distribution will characterize every aspect of most

business and organizational undertakings in the next millen-

nium. Organizations will be challenged to bring ideas and con-

cepts to products and services at an ever-increasing pace. Com-

panies distributed over space, time, and capability will have to come

Amit P. Sheth University of Georgia

Wil van der AalstUniversity of Georgia and Eindhoven University of Technology

Ismailcem B. ArpinarUniversity of Georgia

July–September 1999 19

Does workflowtechnology have afuture?

Since the early 1990s, sev-eral vendors have offeredgeneral-purpose workflow-management systems. Thenumber of workflow prod-ucts offered peaked at some-where between 200 and 300 around 1996and has declined from that point.

Several factors explain this lack of suc-cess in today’s generation of workflow-management systems. First, many pro-jects introducing workflow-managementsystems had to deal with legacy problemsand the burden of application integra-tion. Workflow-management systemswere positioned as a silver bullet thatwould solve all kinds of problems rang-ing from technical issues (such as screenscrapping) to organizational issues (suchas group self-regulation). As a result,they could not meet the expectations.

Second, the lack of real standardscombined with a large volume of ven-dors has created a scattered landscapewhere customers are reluctant to investin workflow products. The numerousworkflow-management systems on themarket today are based on different par-adigms and offer contrasting functional-ity. Third, most of the production-classworkflow-software products offeredtoday are very restrictive and inflexible.

Meanwhile, when the workflow mar-ket started to grow in 1992, other mar-ket segments have started to co-optworkflow capabilities. Enterprise Re-source Planning increasingly supportsworkflow capabilities. Most leading ERPsystems offer a workflow component.Some have developed their own tech-nologies, while others have establishedpartnerships with workflow vendors.

A new market segment that adaptedworkflow functionality is EnterpriseApplication Integration. EAI focuses onapplication interoperability and integra-tion issues within an enterprise. Theaverage Fortune 2000 company relies on49 enterprise-level applications to run itsbusiness and spends 25% to 33% of itsIT budget just to get them to talk to one

another. Overall, an estimated 40% ofall IT expenditure is devoted to system,application, and data integration. Thisexplains EAI’s product appeal, especiallyin organizations where IT managementhas a loud voice. Several EAI productscurrently support limited forms of work-flow capabilities through messaging andpublish-subscribe mechanisms, but thereare signs of future support for morecomprehensive workflow-process capa-bilities. Workflow has become an impor-tant differentiator among the products.

Another new software market seg-ment is e-commerce, which is in themidst of explosive growth. Applicationservers provide support infrastructurefor rudimentary workflows. This ispoised to become increasingly sophisti-cated, and given the attention focused onthis market segment, new workflowtechnologies will likely come about aspart of new e-commerce products. Giventhe marketing advantage, even someworkflow vendors are in the process ofpositioning their products in the e-com-merce segment.

Looking to the future, we discern twotrends. First, vendors are targeting ver-tical sectors or industry-specific solutions(such as telecommunication, healthcare,distribution, transportation, and centraland local government). Domain-specificapplications such as call-center packagesalso reap the fruits of today’s workflowtechnology: Lucent’s call-center productuses InConcert to manage call centerprocesses. Second, given the compli-mentary nature of workflow, EAI, and e-commerce, especially in the context ofvanishing corporate boundaries in thenetworked economy and technologicaladvancement in the Internet age, a newbreed of products will dynamically cre-ate and support virtual communities of

commerce partners. Cur-rent EAI vendors—includ-ing Vitria and Active Soft-ware—are increasinglyadding workflow capabili-ties to achieve a competi-tive advantage, while prod-ucts with roots in workflowincreasingly add EAI capa-bilities. New breeds of

products, such as EAppS from Infocosm(which is based on the University ofGeorgia’s METEOR), are taking anintegrated approach to combine all threecapabilities.

Is it reasonable to say that workflowtechnology has failed? If we narrowlyfocus on the workflow-market segmentand the predominant vendors from a fewyears ago, the answer is perhaps yes.However, we see processes as an organiccomponent of any EAI or e-commercesolution. In this sense, workflow-processtechnology will conduct the emergingnetworked economy from behind thescenes. Current workflow-process tech-nology can arguably be the basis forbuilding future process support for e-commerce.

Prelude to the networkedeconomy: the telecom-munications industryArguably the best example of an industrythat portends the new networked econ-omy is that of telecommunications ser-vices. The telecommunications industryis experiencing a confluence of factorsinvolving globalization, deregulation, andtechnology breakthroughs. Conse-quently, not just the technology, but alsothe businesses are moving at the “speed ofInternet.” In fact the pace of acquisitions,mergers, and alliances sometimes seemsto outstrip the pace of technologicalchanges. The high valuations that WallStreet has afforded to new entrants havefueled entirely new business models, cre-ating a new breed of global corporationsthat in turn have provided opportunitiesfor applying information technology tosolve the challenges. Let’s briefly reviewone of the telecommunications industry’smain drivers: convergence or next-genera-

Web sites for further information

Workflow links (http://www.workflowsoftware.com)

LSDIS Web page (http://lsdis.cs.uga.edu)

Commerce One’s MarketSite.net (http://www.marketsite.net)

LIMITrader Securities Inc. (http://www.limitrader.com)

SciQuest (http://www.sciquest.com)

SigGROUP (http://www.acm.org/siggroup)

The Ontology Group (http://www.ontology.org)

Trading Edge Inc. Bondlink (http://www.tradingedge.com)

VARIA (http://www.varia.com)

20 IEEE Concurrency

tion networks. Generally, this refers to anyof the stages of evolution starting fromthe coexistence and integration of pub-lic-switched telephone networks withpacket-switched data network, to thedevelopment and deployment of a singlecommon packet network for supportingvoice, data, video, and other communi-cations services (including what is termedas VoIP—voice over IP). The businessdriver for convergence is the compellingcost advantage data networks have overswitched networks and tremendousgrowth rate of Internet data traffic (whichdoubles every four months).

Telecommunications service pro-viders are usually divided based on theservices they provide or the parts of net-work they primarily own or control.This includes (a) local exchange carri-ers (LECs) that serve local markets(which are divided into incumbentLECs such as former “baby Bells” andthe newer competitive LECs); (b) longdistance carriers where competitionincreased with deregulation; (c) Inter-net Service Providers including thosesupporting traditional modem, cable,and xDSL technologies; and (d) wire-less service providers. Two of the mostcritical success factors that this highlycompetitive industry has identified arecustomer acquisition and retention, andproviding value-added features andbundled services. Solutions supportingthese two compelling needs invariablyled to the need for interorganizational

workflow because customers prefer todeal with a single service provider, andmost high-value services require inte-grating what different types of pro-viders have to offer.

Architecture for inter-organizational workflowsThe Internet offers the ability to trans-form customer relationships and displacetraditional sources of business valuebecause the source of that value is mov-ing from physical products to digitalones. Customers can now choose theirown hours of business, access services atany location, and receive attention fortheir specific needs. In this respect, com-panies are using the Internet to enternew markets, shrink supply chains, cre-ate new value chains, and meet the chal-lenges of global markets.

Using e-commerce to automate inter-business processes across supply chainspresents significant challenges. Becausecustom point-to-point integrationbetween every buyer and supplier isimpractical, a possible solution is totransform supply chains into open andinteroperable marketplaces.

Some marketplaces host workflowapplications, such as those for purchaseapprovals and accounting. However,most marketplaces do not have enoughfacilities to automate the complex busi-ness processes conducted between buy-ers and sellers. In this respect, workflow

systems should be exploited to modelbuying and selling processes.

Terms such as virtual business processand virtual enterprise clearly demonstratethe relevance of workflows in a net-worked economy. A virtual business pro-cess of a virtual enterprise, also known asinterorganizational workflow, goes be-yond a single enterprise boundary: it isconstructed by combining the servicesdifferent companies (collectively called atrading community) provide. Some of thefundamental issues to address beforeimplementing a virtual enterprise shouldinclude how to provide a mechanismwhereby companies can advertise theirservices and how to execute a virtualprocess that spawns several enterpriseswithout being managed by one physicalenterprise.

We define a marketplace as a logicallycentral location in a networked economywhere sellers offer their goods or services,and buyers come for convenience and theability to compare products and prices.Depending on how various stake hold-ers—consumers, intermediaries, and sup-pliers—interact, and how the capability ofmanaging business processes is realized,we offer three architectures for managingbusiness processes—process portal, processvortex, and dynamically trading processes.

PROCESS PORTALA portal is a one-stop shop for productsor information. Increasingly, it is alsobecoming a one-stop shop for services,which are enabled by applications. Ittakes complex processes involving mul-tiple applications and databases to sup-port or provide such services.

In most current realizations, a portal isresponsible for carrying out a majority ofactivities using the data it has and thetransactions it supports. Some of thesetransactions might involve applicationswithin the organization to which the por-tal belongs, and a few might even be well-defined transactions or informationexchanges with partner organizations (seeFigure 1). Information or traditional e-commerce portals (where selling pack-aged products is the key activity) primar-ily involve application servers anddatabases. A key characteristic of a portal

Figure 1. The process portal marketplace architecture.

July–September 1999 21

is for it to own or manage much of thedata and information it needs to meet cus-tomer needs. More advanced portalsmight use workflow-process support andEAI services to interface with applica-tions, primarily within a single organiza-tion. For example, in the telecommuni-cations industry, applications suited forthis architecture include consumer-to-business e-commerce applications such asintegrated billing and customer self-care.

The same evolution found in other e-commerce activities applies to portals.That is, they first support data (such asWeb publishing), then Web hosting andapplication servers, followed by data-base- and transaction-oriented e-com-merce. Current portals are expected toevolve to host applications (such as ERPsystems) so that a company can out-source its application and data manage-ment.

In the future, we can expect to seemore advanced forms of portals in theform of process portals. A process portalwill manage a variety of customizableprocesses. An individual activity in theprocess might involve participants oraccess to information systems at the sub-scribing company or one of its e-com-merce trading partners.

PROCESS VORTEXThe main distinction between a portalmarketplace and a vortex marketplace isthat interactions between buyers andsellers occur through a third-party mar-ketmaker as opposed to peer-to-peerinteractions between buyers and sellersin a portal (a vortex is not a one-stopshop; see Figure 2). Vortex marketplacesgenerally focus on very specific productlines for specialized markets, and they donot provide access across multiple indus-tries or product groups. Sellers and buy-ers of these products meet with eachother through a particular vortex. How-ever, enterprises might participate in sev-eral marketplaces as sellers or buyers.

Sellers advertise their goods and ser-vices using appropriate tools in the mar-ketplace. The business processes aregenerally designed to incorporate dif-ferent trading models (such as auctions),and they are based on structured trading

rules. The vortex might also provideprocess templates for buyers to realizetheir buying activities. These processesmight involve brokering activities suchas comparison of goods, prices, and soon. Thus, a vortex provides an organicsupport for business processes that areusually determined by process builders,usually from vortex sites and suppliers.

In the vortex model, the marketmakerconverts multiple catalogs from differ-ent vendors into a common ontology.Using a unified ontology, buyers canaccess multiple products from a varietyof suppliers and get all the informationthey need to make a purchase decision.Similar to portal architecture, workflowprocesses are predominantly predefined.However, these processes can be cus-tomized, and they tend to evolve over aperiod of time.

The process vortex architecture be-comes relevant in the telecommunica-tions industry when service providersneed to support different classes of cus-tomers (such as individual residences,small businesses, or large businesses) andrequire flexibility to deal with a limitedset of partners. For example, a CLECmight need flexibility in leasing networkcapacities for long-distance services fromQWEST communications or Level-3communications.

We expect traditional multitier soft-ware architectures to be prevalent inimplementing a vortex. However, intel-

ligent agents might eventually be used tofully realize a marketplace. Instead of asingle buying or selling agent, multiplecoordinated agents will dominate thecommerce process.

DYNAMICALLY TRADING PROCESSESTrading communities focus on verydiverse product lines for several marketsand provide access across multiple indus-tries and product groups. Many complexand intimate concurrent interactionsmight occur between peers. In general,participants in a virtual marketplace are agroup of semiautonomous or autono-mous organizations that need to cooper-ate. This requirement is critical becauseorganizations need to preserve autonomyin a competitive business environment;they derive benefits from their uniquebusiness and technical capabilities. There-fore, they participate in a virtual businessprocess to gain the benefits of being in agroup, but they hide relevant parts of avirtual business process and provide onlypartial visibility to other partners. Con-sequently, business relations are morecomplex, and they are subject to numer-ous constraints.

Because of their relative indepen-dence, business processes can also behighly dynamic in this virtual market-place architecture (see Figure 3). Unlikeportal and vortex architectures, neitherbusiness processes nor the set of possi-ble interactions are predefined. Instead,

Figure 2. Process vortex marketplace architecture. Interactions between buyersand sellers occur through a third-party marketmaker.

22 IEEE Concurrency

a unique process can be dynamically con-structed on a per customer basis. Thatis, based on a customer’s needs and pref-erences, a virtual process is constructedon the fly to meet a specific demand asdepicted in Figure 3. Note that ? and Xon the edges within the workflow pro-cesses and relationships between com-panies indicate this dynamic nature ofconstructing business processes. In gen-eral, this process would take eachselected company’s capabilities and ser-vices into consideration. In a more com-plex scenario, because a customer mightwish to deal with a single company topurchase several goods and services atonce, that particular company mightstart a purchasing process. According tonegotiations with other companies, miss-ing components of the overall processthat meet the customer’s needs would beconstructed one by one in a way thatbrings all the pieces of the puzzletogether. This shows that a very flexibleand adaptable process support mecha-nism is needed to support dynamicallytrading processes in a virtual market-place.

An example of this architecture’sapplication in the telecommunicationsindustry is as follows. One of our visionsof future networks includes the facilityto allow consumer devices to interactwith other devices and humans on thenetwork in an integrated fashion. Herethe device might be able to specify a needfor a specific type and quality of networkservices required, and the network willbe able to dynamically compose a cus-

tomized process to process the request.Additionally, this process might considerthe overall value of the process to thecustomer and the need to maximize thevalue of the service provided by the busi-ness to different customers with differ-ent QoS requirements. All the while, thesets of consumers, suppliers, and servicedemands might be changing, making thisa highly dynamic environment.

Key technologies

In the last decade, many software devel-opers and researchers have worked onconcepts, methodologies, techniques,and tools to support workflow-processmanagement. Given the networked econ-omy’s requirements in the next millen-nium and the corresponding architec-tural alternatives discussed earlier, let’sdiscuss some of the key technologies orcomponents of workflow-process man-agement along with the problems theyneed to solve.

WORKFLOW DESIGNMany perspectives characterize a work-flow design.2 The dominant perspectivesare process, organization, information,and operation. In the process perspec-tive, workflow-process definitions (workflowschemas) are defined to specify whichtasks need to be executed and in whatorder. A task is an atomic piece of work.Workflow-process definitions are in-stantiated for specific cases,3 examples ofwhich include a request for a mortgageloan, an insurance claim, a tax declara-

tion, or an order for a new telecommu-nications service. Because a case is aninstantiation of a process definition, itcorresponds to the execution of concretework according to a specified routing orset of business rules.

In the organization perspective, theorganizational structure and the populationare specified. The organizational structuredescribes relations between roles (resourceclasses based on functional aspects) andgroups (resource classes based on organi-zational aspects) and other artifacts clari-fying organizational issues (such as res-ponsibility and availability). Resources,ranging from humans to devices, form theorganizational population and are allo-cated to roles and groups.

The information perspective dealswith control and production data. Controldata are introduced solely for workflow-management purposes (variables intro-duced for routing). Production data areinformation objects (such as documents,forms, or tables) whose existence doesnot depend on workflow management.

The operation perspective describesthe elementary operations resources andapplications perform. Typically, theseoperations are used in the process per-spective to create, read, or modify con-trol and production data in the informa-tion perspective. Most operations are(partially) implemented by applications.

The integration perspective is the linkbetween the other four perspectives (seeFigure 4). Activities (also called tasks orsteps) and workflow-process definitionsidentified in the process perspective arelinked to roles, groups, and resources inthe organization perspective, data ele-ments in the information perspective, andoperations in the operation perspective.Operations in the operation perspectiveare linked to data elements in the infor-mation perspective, and so on. A work-flow definition (also called a workflowtype) is the specification of a workflowthat covers all these aspects. Cases areinstances of a workflow type and are han-dled accordingly. A workflow-managementsystem aims at supporting the five per-spectives shown in Figure 4. The build-time service of the workflow-manage-ment system allows for the specification

Figure 3. Dynamically trading processes.

July–September 1999 23

of these perspectives. The workflow-management system’s enactment servicetakes care of the actual enactment.

The process perspective is the centerof any workflow design. Many languageshave been proposed for designing work-flow-process definitions. These lan-guages are typically graphical and usebuilding blocks such as OR-split, OR-join, AND-split, and AND-join tomodel sequential, parallel, conditional,and iterative routing. Figure 5 shows anexample of a workflow-process defini-tion modeled with the METEORbuilder. The workflow-process defini-tion consists of 13 tasks and specifies theprocessing of travel requests. Condi-tional arcs model the causal relationsbetween tasks. The routing conditionsdepend on control data specified in theinformation perspective. METEORsupports the explicit modeling of theworkflow perspective, but most work-flow-management systems do not havesuch a facility: the information perspec-tives (and the operation perspective) aremodeled implicitly as extensions of theworkflow-process definition. The onlyperspective that is typically modeled inseparate diagrams is the organizationperspective.

Lack of adequate standards forworkflow modelingIn the last decade, many languages havebeen proposed for modeling workflow-process definitions. In fact, in the early1970s, researchers worked on techniquesfor the modeling of office procedures.Most workflow-management systems usea graphical design language where tasksare connected by arrows and routing ele-ments. Despite the efforts of standardiza-tion bodies such as the Workflow Man-agement Coalition (WfMC), there is noreal consensus on the representation ofworkflow processes. Standards such as

Interface 1 of the WfMC and PIF(Process Interchange Format) focus onthe syntax of the modeling languagerather than support specifications ordescriptions of process semantics. PIF isan interchange format designed to helpautomatically exchange process descrip-tions among a wide variety of processtools such as process modelers, workflowsystems, process repositories, and so on.These tools can interoperate by translat-ing between their native process descrip-tion format and PIF, and vice versa. Otherstandardization efforts such as Interface4 of the WfMC, focus on interoperabilityissues rather than on a uniform designlanguage.

The lack of real standards for workflowmanagement can be explained by com-paring the current situation with the earlydays of database-management systems. Inthe early ’70s, most of the pioneers in thefield of database-management systemswere using their own ad hoc concepts.This disorder and lack of consensusresulted in an incomprehensive set of data-base-management systems. However,emerging standards such as the relationaldata model and the entity-relationshipmodel led to a common formal basis formany database-management systems. Asa result, their use was boosted.

Until now, such a formal basis wasmissing from the workflow domain.Many researchers advocate the use ofPetri nets as a formal basis for workflowmodeling. The Petri net formalism com-bines a strong mathematical foundationwith an intuitive graphical representa-tion. Several workflow-management sys-

tems use a modeling language based onPetri nets (such as COSA, INCOME,BaanERP, and SAP R/3). However, mostworkflow systems use a vendor-specificdiagramming language. These diagram-ming languages typically abstract fromstates and do not allow for advanced rout-ing constructs involving a mixture ofchoice and synchronization. As a resultof these and other limitations, it is diffi-cult to translate a workflow-process def-inition from one system to another. Fromthe organization perspective, there areeven fewer consensuses. Some workflow-management systems use a simple role-based mechanism in which there is onework queue for each role. Other systems(such as COSA) provide an advancedscripting language with multiple alloca-tion dimensions that include roles,groups, and authorizations.

Perspectives, languages, anddefinitionsThe technology for designing andexchanging information and operationperspectives is mature and can be usedfor e-commerce applications and otherfuture workflow applications. However,the organization perspective is underde-veloped compared to the others. In a net-worked economy, workflow processeswill cross organizational boundaries, andthese boundaries will become fluid andsubject to continuous change. For exam-ple, the difference between a customerand an employee is fading. Traditionally,a customer would be outside of an orga-nizational model, but customers willincreasingly track orders over the Web

Figure 5. Workflow-process definition.

Figure 4. The five perspectives in aworkflow-management system.

24 IEEE Concurrency

using the same software as employees.Furthermore, in future e-commerceapplications, the customer will be able toinfluence the underlying workflow pro-cess by updating requests or supplyingadditional information. This will requirenew paradigms to design and manage theorganization perspective accurately andeffectively.

The limited expressive power of thedesign languages used by today’s work-flow-management systems continues tobe a source of problems. Most work-flow-management systems are not ableto model states—they can’t model mile-stones or let the environment select thenext step. These systems also have prob-lems dealing with situations involving amixture of synchronization and choice.In fact, the majority of workflow-man-agement systems use a design languagethat corresponds to the so-called classof free-choice Petri nets.3 It is well-known that the expressive power of thisclass is limited compared to standardPetri nets.

Another persistent issue is the reuse ofworkflow-process definitions. Althoughworkflow processes within differententerprises have common elements, theyare typically designed from scratch.Within large companies it is often impos-sible to specify a workflow-process defi-nition once and replicate it across all partsof the company that need it.

Uniform solutionsLocal differences have to be taken intoaccount to prevent the use of one uni-form solution to any of these problems.As a result, workflow processes are typ-ically designed from scratch and thewheel is re-invented every day. To avoidthis, we can use workflow templates,which is a standard design of a commonworkflow process. Templates let design-ers reflect local differences (resultingfrom specific regulations, organizationalstructures, and other particularities) andstill re-use common parts.

The idea of using templates for work-flow processes is not new. Today’s ERPsystems offer hundreds of readymadeworkflow templates (often called businessor reference models) that can be used as

a starting point for configuring a system.These workflow templates are oftenbased on “best business practices” andreflect the experiences of leading enter-prises. Although the set of workflow tem-plates offered by today’s workflow-man-agement systems is still limited, wepredict the use of templates will increaseto avoid starting from scratch every timea new workflow has to be designed. Tem-plates can be shared between differententerprises in the process portal or vortexarchitectures, thus providing a basis forcommon understanding and shared busi-ness intelligence.

WORKFLOW ANALYSISThe correctness, effectiveness, and effi-ciency of the business processes theworkflow-management system supportsare vital to the organization. A workflow-process definition that contains errorsmight lead to angry customers, backlog,damage claims, and loss of goodwill.Flaws in a workflow definition’s designmight also lead to high throughput times,low service levels, and a need for excesscapacity. This is why it is important toanalyze a workflow-process definitionbefore it is put into production. Basically,there are three types of analyses: verifica-tion, validation, and performance.

Verification focuses on syntactic cor-rectness; it is independent of the context—it refers to the minimal requirements anyworkflow should satisfy. For example,there should be no tasks without inputconditions. Note that syntactic correct-ness not only refers to the workflow-process definition’s structure but also todynamic behavior and other perspectives.Examples of syntactic errors in the orga-nizational perspective are roles andgroups without any members and cyclichierarchical relations. Syntactic errors inthe integration perspective are pointersto entities in another perspective thatdoes not exist (such as when a task pointsto a removed role). Potential deadlocksand livelocks are examples of syntacticerrors in the process perspective. Animportant correctness criterion is the so-called soundness property that guaranteesproper termination, which means thatthe predefined final state is reached and

that there are no dangling referencesafter termination.3

Validation is concerned with the fol-lowing question: Is the mapping from the(desired) real-world situation to theworkflow design correct? Validationfocuses on semantic correctness. Todetect semantic errors, knowledge of theapplication domain is needed. For exam-ple, sending a bill before a delivery is con-firmed is a semantic error, not a syntac-tic one. Verification and validation onlyconsider the logical correctness of theworkflow processes rather than quanti-tative measures such as time and costs.

Performance analysis focuses on quan-titative measures such as average orderlead time, percentage of cases handledwithin a week, number of cases inprogress, and utilization of bottleneckedresources. Today’s workflow-manage-ment systems give limited support to per-formance analysis—they provide a rudi-mentary simulator or a gateway to asimulation tool. Simulation can estimatekey performance indicators by experi-menting with the specified workflowunder an assumed specific environmentalbehavior. Most workflow-managementsystems do not give any support forworkflow verification. As a result, work-flow-process definitions become opera-tional before they are thoroughlychecked for correctness. This often re-sults in runtime errors that need to berepaired on the fly at high cost.

Verification of workflow-processdefinitionsFor decades, research groups all over theworld have worked on verification tech-niques. These techniques have checkeddesigns of communication protocols,multiprocessor systems, traffic systems,manufacturing systems, and consumerelectronics. State-of-the-art verificationtechniques let researchers analyze thesesystems, which typically have millionsof states.

The applications mentioned aremainly technical; there are hardly anyexamples of the use of verification tech-niques for analyzing business processes.Business processes are often hiddeninside application software, informal

July–September 1999 25

business rules, and the minds of the peo-ple involved in the process. Moreover,the expertise required to use verificationtechniques is often missing in the busi-ness domain. However, the widespreaduse of standardized software for businessprocesses (such as workflow-manage-ment systems, ERP systems, and BPRtools) is changing this situation. Theexplicit representation of workflowprocesses enables the use of verificationtools. A typical workflow process con-sisting of 50 tasks can easily have up tohalf a million potential states for a singlecase! Therefore, we need advanced ver-ification techniques. Several groupsaround the world are working on verifi-cation techniques for workflow-processdefinitions. Most of these groups usetechniques based on Petri net theory.One workflow-verification tool, Woflan,can import workflow-process definitionsfrom several workflow-management sys-tems and has analyzed realistic and com-plex workflows.

Current toolsBoth manufacturers and users of work-

flow-management systems see the needfor analysis capabilities. However, few sys-tems have reached a level where verifica-tion, validation, and performance analy-ses are supported in a satisfactory manner.For example, none of the commerciallyavailable workflow-management systemsoffer verification capabilities that gobeyond trivial checks such as the absenceof an initial task or input condition. Inmost workflow-management systems, it ispossible to model the synchronization(say, AND-join) of two alternative paths(in this case, two paths starting with anOR-split) without any warning at designtime. At runtime, such a construct willinevitably result in deadlocks.

Consider, for example the workflow-process definition (modeled with theMETEOR builder) shown in Figure 6.Compared to the workflow shown inFigure 5, this figure contains a causalrelation between ReserveTickets1 andReserveTickets2 (task ReserveTickets2can only be executed if ReserveTickets1and either CheckApproval2 or Confirm-Approval2 has been executed with a pos-itive result). This workflow deadlocks if

the lower part of the workflow is acti-vated. Moreover, if the upper part is cho-sen, the workflow will not be able to ter-minate properly because the trigger fromtask ReserveTickets1 to ReserveTickets2is still there, resulting in a dangling ref-erence to a case that does not exist any-more. Figure 6 shows the diagnostics theworkflow-verification tool Woflan pro-vided that indicate the error’s source.The workflow-process definition madewith METEOR was imported byWoflan, which automatically translatedthe process definition into a Petri net andused various analysis techniques (cover-ability graph, linear algebraic techniques,and structural methods) to locate theerror. Woflan can also download work-flow-process definitions from a limitednumber of other workflow tools. Giventhe availability of the technology, it isremarkable that today’s workflow-man-agement systems offer hardly any verifi-cation support. Especially in environ-ments such as the networked economywhere changes are frequent and disrup-tive, the added value of good verificationfacilities is considerable.

Figure 6. Verification of a workflow designed with METEOR using Woflan.

26 IEEE Concurrency

Short-term simulationEnterprise information systems (pow-ered by workflow-management systems)have knowledge of business processes,the current state of each process, and his-torical data. This knowledge enables theapplication of a special form of decisionsupport: short-term simulation, whichexploits the information that is available.Decisions that affect the businessprocesses in the near future can be eval-uated without the need for any additionalmodeling efforts. The structured stor-age of information in an enterprise sys-tem enables a relatively simple creationof a simulation model. Several workflow-management systems support simulationor provide a gateway to existing simula-tion tools. For example, ExSpect cansimulate COSA workflows, the businessprocessing reengineering tools ARIS andBusinessSpecs can import and exportStaffware procedures, and Meta Soft-ware’s workflow analyzer can interfacewith Visual WorkFlo and FloWare.These simulation facilities supportstrategic decision-making.

However, in enterprises where work-flow-management systems are used, wealso need decision support for manage-ment and operational control. The tradi-tional approach toward simulation doesnot work for this purpose because itfocuses on strategic decisions with long-term effects. Research efforts should aimat simulation facilities that are concernedwith the effects of a decision in the nearfuture and exploit all the informationavailable including the actual current

state. Such facilities can provide managerswith a kind of fast-forward button. Bypushing this button, we can see the cur-rent situation extrapolated. We can alsosee the effect of certain decisions (forexample, hiring additional employees orrenouncing new orders) in the nearfuture. Advanced analysis capabilities forverification, validation, and performanceanalysis will give managers the tools toreact promptly to the ever-increasing paceof change. The applicability of the nextgeneration of workflow-management sys-tems depends on these capabilities.

ENACTMENTA workflow-enactment service consistsof execution-time components that pro-vide workflow processes with an execu-tion environment. It enforces intertaskdependencies, schedules tasks, managesworkflow data, and ensures a reliableexecution environment. Most workflow-management systems and many EAI sys-tems adequately support basic features(mainly scheduling tasks by interfacingthem with applications and supportinghuman participation) and a variety ofoptional and advanced features such asmonitoring, animation, and reporting.

Most workflow systems today employa three-tier client-server architectureand involve external applications thatperform geographically distributed taskson different platforms. Most existingworkflow-runtime systems are still cen-tralized in the sense that a single work-flow engine handles an entire processexecution. Unfortunately, this central-

ized architecture cannot support reliableand consistent process execution withincreased failure resiliency, performance,and scalability.

In a fully distributed architecture, thecentralized engine is eliminated, andenactment is achieved through geo-graphically dispersed workflow compo-nents. In general, the main componentsof a workflow-enactment architectureare the workflow scheduler and taskmanagers that manage individual taskson the system’s behalf. A workflowscheduler could be either centralized ordistributed. Distributed object-basedarchitectures or lightweight agent-basedsystems provide better infrastructure fordynamically trading processes and formaking the process management organicand integral to the systems that will sup-port applications in a networked econ-omy. Figure 7 shows an evolution in thearchitecture of workflow-enactmentservices.

Two examples of fully distributedenactment services are the ORBWorkand WebWork components of theMETEOR system and its commercialversion, EAppS. WebWork relies onlyon the Web for its infrastructure, whileORBWork exploits Web, Java, andCORBA (including some services). Nei-ther have a single entity responsible forscheduling task-manager activation.Instead, the scheduling information isdistributed among the individual taskmanagers. Each task scheduler has thenecessary information about its immedi-ate predecessor and successor tasks, thusit is capable of activating the successortask schedulers once the task it controlsterminates. Another example of a dis-tributed architecture is Wide (Workflowon Intelligent and Distributed databaseEnvironments), which is a spin-off of aEuropean Commission project. Wide isa workflow system that provides a dis-tributed environment based on an activedatabase-management system to supportworkflow enactment. It is based on aclient-server architecture where theagents working within the system acti-vate clients.

Recently, a lightweight approach wasproposed to meet the needs of today’s

Workflow asdistributed/cooperating

objects/agents

Organicprocesssupport

Mobile agentsFully distributed

Multiple servers

Time

Evolution ofarchitectures

Centralizedengine/single

server

Client-server/web-enabled

Figure 7. Evolution of workflow-runtime system (enactment service)architectures.

July–September 1999 27

highly dynamic electronic business envi-ronment. In this approach, workflowenactment is achieved by a collection ofautonomous, problem-solving agents.This approach is explained briefly in the“QoS: Achilles’ Heel of workflow man-agement” section.

The next two implementation archi-tectures (distributed cooperating objectsor agents and organic process support)are rather new compared to other archi-tectures. In the first architecture, differ-ent workflow components can be real-ized as distributed cooperating objects,and a naming service can be utilized as away of providing location transparencyfor these components. For example, allof the ORBWork components—taskschedulers, task managers, data objects,and so on—are implemented as CORBAobjects, and the ORBWork scheduler iscomposed of a network of cooperatingtask-scheduler objects. As we mentionedearlier, processes will become an organiccomponent of any EAI or e-commercesolution in the near future. So, we expectto see a workflow-runtime architectureas an integrated component of futurecritical-enterprise application servers.Systems from Infocosm, Vitria, andSilknet exemplify such a move.

QoS: Achilles’ Heel of workflowmanagementAnecdotal reports from industry increas-ingly suggest that systems fail to define,let alone measure and publish, QoSinformation. Many products suffer formlarge process space or virtual memoryrequirements, while others fail to utilizemultithreading or multiple distributedserver capabilities in a distributed com-puting environment. Adoption of work-flow management for supporting mis-sion-critical functions in a networkedeconomy will require significant addi-tional progress.

An enactment service should be scal-able in terms of carrying large loads.Therefore, partitioning a potentiallylarge load among participating compo-nents and guaranteeing minimal com-munication between these componentsare essential to provide scalability. Theerror-handling and recovery framework

for a workflow system should also bedefined in a scalable manner (for exam-ple, by partitioning the recovery mech-anism across local hosts).

Transactional aspects such as recov-ery, atomicity, and isolation to ensurecorrect and reliable workflow executionsare studied in the context of workflowsystems. Failures could occur at variousstages within the workflow-enactmentprocess’s lifetime. Reliability requiresthat tasks, their associated data, and theworkflow system itself be recoverable inthe event of failure, and that a well-defined method exists for recovery. Insome workflow systems, failure atomic-ity is ensured through forward and back-ward recovery. Other traditional recov-ery techniques such as logging are alsosuccessfully used in workflow systems.However, because workflow processesare more complex and fundamentallydifferent from ACID (atomicity, consis-tency, isolation, durability) transactions,adequate solutions for transactional sup-port in workflow systems are stillmissing.

The term transactional workflow wasintroduced in 1993 and further elabo-rated on4 to recognize transaction rele-vance in workflows. Transactionalworkflows support selective use of trans-actional properties for individual tasksor entire workflows.

Another critical challenge for a work-flow-enactment service is its ability torespond effectively when exceptionsoccur. In general, an exception can beconsidered to be any deviation from aprocess that achieves the process goalscompletely and efficiently. Workflowexceptions can be categorized as work-flow-system-specific exceptions (forexample, exceptions due to system fail-ures) and workflow-application-specificexceptions (such as exceptions due toincorrectly performed tasks or when adeadline for a task expires).

Currently, workflow systems providelittle support for exception management.These systems typically assume a more orless idealized process. In particular, whenexceptions occur, workflow systems main-ly rely on the database environment’srecovery capability, or users are forced to

go behind the workflow system’s back,making the system more of a liability thanan asset. In some research prototypes,rule-based approaches or artificial intelli-gence (knowledge-based) techniques de-tect and resolve workflow exceptions.

The highly dynamic and unpredictablenature of business processes makes agenttechnology appealing. A workflow-man-agement system architecture can bedesigned to consist of functionality basedreusable components, each of which isrealized through different agents. Forexample, at the lowest level, task agentscan be used to invoke different types oftasks. A scheduling agent can be used tosupport dynamic changes on control flowthat emerge from workflow-agent nego-tiation at runtime.

Organizational modeling andother open issuesTomorrow’s networked economy re-quires a powerful and reliable executionenvironment to enact business processesthat can span the boundaries of multipleorganizations. Significant additionalresearch and serious engineering effortsare needed to improve scalability, excep-tion handling, automatic recovery, andother QoS criteria.

Building all these capabilities fromscratch within a workflow system with-out using any state-of-the-art supporttools is not an easy task. In this sense,Iona Technology’s OrbixOTM 3.0 withJava and security support for e-com-merce applications seems promising inproviding transactional capabilities in aCORBA-based workflow-system imple-mentation. Another promising infra-structure is the one provided by BEA’sM3 system.

Organizational modeling in a virtualenterprise and the use of role hierarchiesfor the enactment of virtual processesare other important research topics.Tomorrow’s networked economy mightrequire several organizations to con-tribute to a single organizational model,and this model might be changed on thefly through a flexible role-domain de-sign tool.

Agent-based workflow-managementsystems still have a long path ahead

28 IEEE Concurrency

before they will effectively address QoSissues.

INTEROPERABILITYVirtual business processes that operateacross enterprises might be implementedusing a set of workflow definitions cre-ated to support discrete segments of theoverall process. To avoid creating islandsof automation, different workflow prod-ucts should talk to each other byexchanging messages that affect processinteroperation and integration. There-fore, workflow systems in an organiza-tion need to successfully interoperateboth internally at the department leveland externally with the organizationswith which they do business. This canapply to external parties such as vendors,other businesses, and customers. Toachieve wide-scale interoperability be-

tween organizations, cooperation be-tween workflow vendors is critical.

The problem of workflow interoper-ability has many facets, ranging fromtechnological issues about how to inte-grate different workflow-managementsystems of different vendors on differ-ent platforms to the purely conceptualissues of specifying how the interactionshould occur. Unplanned interoperabil-ity of different workflows, which areautonomously and separately designed,might cause problems such as deadlocks,starvation, livelocks, or failure to termi-nate in the desired final state.

SpecificationsIn general, we can classify interoperabil-ity specifications for workflow systemsinto two categories: specifications formodeling and workflow description, and

specifications for runtime interoperabil-ity. PIF and the WfMC’s Process Defin-ition Interchange (Interface 1) standardfall into the first category, and they pro-vide a standard format for representingworkflow specifications. These standardformats exchange workflow specificationsbetween different workflow products. Onthe other hand, newly emerging productssuch as the Simple Workflow Access Pro-tocol (SWAP), OMG’s jointFlow stan-dards, and WfMC’s Interoperability(Interface 4) specification aim to supportexchanging process enactment informa-tion or interoperability at runtime. Theyprovide interfaces for operations to sup-port the integration and interactionsbetween workflow systems. Typical oper-ations include operations to create in-stances of the particular process type andoperations to report a workflow instance’s

Articles for further information

In this box, we provide some references for further informationfor some issues presented in this article.

Does workflow technology have a future?D. Sholler, ENT News and Views, 9 Dec. 1998, p. 16; http://www.entmag.com.

Prelude to the networked economy: the telecommu-nications industry

G. Lenahan. “A Practical View of Network Evolution,” Next Gen-eration Networks, 1998; http://www.telcordia.com.

The Secret Sauce of Convergence, J.P. Morgan Securities Inc., NewYork, 14 Dec. 1998.

Readings in electronic marketplace architecturesG. Alonso et al., “WISE: Business to Business E-Commerce,” IEEENinth Int’l Workshop on Resource Issues on Data Engineering,IEEE Computer Soc. Press, Los Alamitos, Calif., 1999.

S. Arpinar, A. Dogac, and N. Tatbul, “An Open Electronic Mar-ketplace through Agent-based Workflows: MOPPET,” Int’l J., tobe published in 1999.

Enabling the Business-to-Business Trading Web Using marketSite3.0 Open Marketplace Platform, Commerce One, New York, Mar.1999.

Comm. ACM (Special Issue), Vol. 2, No. 3, Mar. 1999.

G. Dalton, “Bazaar Advantages,” Information Week, 10 May 1999.

Reference Architecture for iMarkets, Part 1 Overview. Draft 1.1,The Ontology Group, Sep. 1998; http://www.ontology.org.

Lack of adequate standards for workflow modelingW.M.P. van der Aalst, “Three Good Reasons for Using a Petri-net-based Workflow Management System,” Information and ProcessIntegration in Enterprises: Rethinking Documents, T. Wakayamaet al., eds., Kluwer Academic Publishers, Norwell, Mass. 1998, pp.161–182.

C.A. Ellis, and G.J. Nutt, “Modelling and Enactment of Workflow

Systems,” Application and Theory of Petri Nets , M. AjmoneMarsan, ed., Springer-Verlag, Berlin, 1993, pp. 1–16.

PIF: The Process Interchange Format v.1.2, PIF Working Group,Dec. 1997; http://ccs.mit.edu/pif.

Interface 1: Process Definition Interchange Process Model, Work-flow Management Coalition, http://www.aiim.org/wfmc, Nov. 1998.

M.D. Zisman, Representation, Specification and Automation ofOffice Procedures, PhD thesis, Univ. of Pennsylvania, WartonSchool of Business, 1977.

Verification of workflow process definitionsW.M.P. van der Aalst, “Verification of Workflow Nets,” Applica-tion and Theory of Petri Nets, P. Azema and G. Balbo, eds.,Springer-Verlag, Berlin, 1997, pp. 407–426.

N.R. Adam, V. Atluri, and W. Huang, “Modeling and Analysis ofWorkflows using Petri Nets,” J. Intelligent Information Systems,Vol. 10, 1998, pp. 131–158.

A.H.M. ter Hofstede, M.E. Orlowska, and J. Rajapakse, “Verifica-tion Problems in Conceptual Workflow Specifications,” Data andKnowledge Engineering, Vol. 24, No. 3, 1998, pp. 239-256.

M. Voorhoeve, “Modeling and Verification of Workflow Nets,”Workflow Management: Net-based Concepts, Models, Techniquesand Tools (WFM’98), W.M.P. van der Aalst, G. De Michelis, andC.A. Ellis, eds.., Computer Science Reports, Eindhoven Univ. ofTechnology, Eindhoven, The Netherlands, 1998, pp. 96–108.

QoS: Achilles’ Heel of workflow managementI.B. Arpinar et al., “Formalization of Workflows and CorrectnessIssues in the Presence of Concurrency,” Int’l J. Distributed and Par-allel Databases, Vol. 7, No. 2, Apr. 1999.

D. Barbara et al., “INCAs: Managing Dynamic Workflows in Dis-tributed Environments,” J. Database Man., Winter 1996, pp. 5–15.

F. Casati, Models, Semanics and Formal Methods for the Design ofWorkflows and Their Exceptions, PhD thesis, Politecnico di Milano,Italy.

S. Ceri et al., “WIDE: A Distributed Architecture for Workflow

July–September 1999 29

status changes. Once a workflow systemsupports these interfaces, it can talk withother workflow products by exchangingprocess control and status informationthrough common operations.

The 1998 WfMC Interface 4 specifi-cation lets workflow systems from mul-tiple vendors interoperate with oneanother. It defines the mechanisms thatworkflow product vendors are requiredto implement for one workflow engineto make requests of another. In April1999, WfMC announced that severalvendors had developed the first WfMCInterface 4-compliant products.

SWAP is an Internet-based standardfor interoperable workflow productsfrom multiple vendors. The SWAP spec-ification, which is still in draft status, usesHTTP and XML to enable organiza-tions to extend their existing workflow

applications out to other organizationson the Internet and Extranets. SWAP isbased on jointFlow’s object model andthe WfMC’s workflow architecture.

A group of companies submitted thejointFlow specification in response toOMG’s Workflow Management FacilityRFP in 1998. jointFlow addresses therequirements for interoperability betweendifferent workflow-system implementa-tions in a CORBA environment.

Open IssuesAlthough some standardization effortsare under development, interoperabilityspecifications are still far from meetingthe interoperability needs of workflowsystems, especially those that operate ina virtual business environment. Mostruntime interoperability standards makeassumptions about the middleware or

implementation infrastructures. Withmultiple organizations participating, theonly common ground to be expected isthe Internet (HTTP, XML, and possi-bly Java). Hence, the interoperabilitysolutions need to evolve toward multi-protocol and more heterogeneous mid-dleware environments.

In the context of interorganizationalworkflows, the issue of organizationalmodeling will become critical. In thefuture, we expect that workflow specifi-cations will increasingly interact withorganization models (including securitypolicies and models, business rules, andso on) that will differ for various partic-ipating organizations. The current inter-operability specifications do not supportorganizational aspects in any significantway. Supporting organizational modelswith respect to the multiple participat-

Management,” Proc. Seventh Int’l Workshop on Reseach Issues inData Engin., IEEE Computer Soc. Press, Los Alamitos, Calif., 1997.

A. Cichocki and M. Rusinkiewicz, “Migrating Workflows,” Work-flow Management Systems and Interoperability, A. Dogac et al.,eds., Springer-Verlag, Berlin, 1998.

C. Hagen and G. Alonso, “Flexible Exception Handling in theOPERA Process Support System,” Proc. 18th Int’l Conf. on Distrib-uted Computing Systems, IEEE Computer Soc. Press, Los Alamitos,Calif., 1998.

M. Huhns and M. Singh, “Multiagent Systems in Information-RichEnvironments,” Proc. of Second Int’l Workshop on CooperativeInformation Agents, Springer-Verlag, Berlin, 1998.

K.J. Kochut, A.P. Sheth, and J.A. Miller, “Optimizing Workflow: Usinga CORBA-based, Fully Distributed Process to Create Scalable, DynamicSystems,” Component Strategies, Vol. 1, No. 9, 1999, pp. 45–57.

N. Jennings et al., “Agent-Based Business Process Management,”Int’l J. Coop. Info. Systems, Vol. 5, Nos. 2–3, 1996.

J. Miller et al., “WebWork: METEOR’s Web-Based Workflow Man-agement System,” J. Intelligent Info. Systems, Vol. 10, No. 2, Mar.1998.

S. Wheater et al., “A CORBA Compliant Transactional WorkflowSystem for Internet Applications,” Proc. IFIP Int’l Conf. DistributedSystem Platforms and Open Distributed Processing, IEEE ComputerSoc. Press, Los Alamitos, Calif., 1998.

D. Wodtke et al., “The MENTOR Workbench for Enterprise-wideWorkflow Management,” Proc. ACM SIGMOD Int’l Conf. Man-agement of Data, ACM Press, New York, 1997.

Workflow interoperability specificationsM. Anderson and R. Allen, Workflow Interoperability: EnablingE-Commerce, White Paper, http://www.aiim.org, Apr. 1999.

F. Casati et al., “Semantic WorkfFlow Interoperability,” Proc. EDBTConf., 1996.

W. Schulze, C. Bussler, and K. Meyer-Wegener, “Standardizing onWorkflow-Management: The OMG Workflow Management Facil-ity,” ACM SIGROUP Bulletin, Vol. 19, No. 3, Apr. 1998.

SWAP Working Group, Requirements for Simple Workflow AccessProtocol, Internet Draft, SWAP Working Group; http://www.ics.uci.edu /~ietfswap, Nov. 1998.

Research on adaptabilityA. Sheth, “From Contemporary Workflow Process Automation toAdaptive Dynamic Work Activity Coordination and Collaboration,”Proc. Workshop on Workflows in Scientific and Engineering Appli-cations, IEEE Computer Soc. Press, Los Alamitos, Calif., 1997.

F. Casati et al., “Workflow Evolution,” Data and Knowledge Engi-neering, Vol. 24, No. 3, 1998, pp. 211–238.

C. S. Ellis, K. Keddara, and G. Rozenberg, “Dynamic Change withinWorkflow Systems,” Proc. Conf. Organizational Computing Systems,N. Comstock and C. Ellis, eds., ACM, New York, 1995, pp. 10–21.

M. Klein, C. Dellarocas, and A. Bernstein, eds., Proc. CSCW-98Workshop Towards Adaptive Workflow Systems, ACM Press, NewYork, 1998.

M. Reichert and P. Dadam, “ADEPTflex: Supporting DynamicChanges of Workflow without Loosing Control,” J. IntelligentInformation Systems, Vol. 10, No. 2, 1998, pp. 93–129.

G. Vossen and M. Weske, “The WASAZ Object-Oriented Work-flow Management System,” Proc. ACM SIGMOD, ACM Press, NewYork, 1999, pp. 587–589.

GeneralA. Dogac et al., eds., “Workflow Management Systems and Inter-operability,” NATO ASI Series, Springer-Verlag, Berlin, 1998.

D. Georgakopoulos, M. Hornick, and A. Sheth, “An Overview ofWorkflow Management: From Process Modeling to WorkflowAutomation Infrastructure,” Distributed and Parallel Databases,Vol. 3, 1995, pp. 119-153.

R. Kalakota and A.B. Whinston, Frontiers of Electronic Commerce,Addison-Wesley, Reading, Mass., 1996.

P. Lawrence, ed., Workflow Handbook 1997, Workflow Manage-ment Coalition, John Wiley & Sons, New York, 1997.

V. Zwass, “Electronic Commerce: Structures and Issues,” Int’l J.Electronic Commerce, Vol. 1, No. 1, 1996, pp. 3–23.

30 IEEE Concurrency

ing organizations involved in dynamicand adaptive workflows will become anincreasingly complex issue.

ADAPTABILITYA critical challenge for workflow-man-agement systems is their ability torespond effectively to changes. Changesmight range from ad hoc modificationsof the process for a single customer to acomplete restructuring for the workflowprocess to improve efficiency. Today’sworkflow-management systems are illsuited to deal with change; they typicallysupport a more or less idealized versionof the preferred process. However, thereal runtime process is often much morevariable than the process specified atdesign time. The only way to handlechanges is to go behind the system’sback. If users are forced to bypass theworkflow-management system quitefrequently, the system is more a liabil-ity than an asset.

To increase workflow-managementsystem flexibility, it is crucial to knowwhat kinds of changes need to be sup-ported. Basically, there are three kinds ofexternal circumstances that might trig-ger change: business (motivated bychanging markets or individual customerdemands), legal (triggered by new legis-lature), and technological context (intro-duction of new technology or change ininfrastructure). Change can also be trig-gered by developments inside the system.It is important to distinguish between adhoc and evolutionary changes.

Ad hoc and evolutionary changesAd hoc changes affect only one case or aselected group of cases. The change is theresult of an error, a rare event, or a cus-tomer’s special demands. In general, it isnot necessary to change the workflowdefinition, because the change will mostprobably not happen in this constellationagain. A typical example of an ad hocchange’s root is the need to skip a task incase of an emergency. This change isoften initiated by some external factor.

Evolutionary changes are of a struc-tural nature: from a certain moment intime, the workflow changes for all newcases that arrive in the system. The

change is the result of a new businessstrategy, reengineering efforts, or a per-manent alteration of external conditions.Management typically initiates evolu-tionary change to improve efficiency orresponsiveness, or it is forced by legisla-ture or changing market demands.

Both ad hoc and evolutionary changesare possible at entry time and on the fly.Customizing the process definition for asingle case before the processing startscorresponds to an ad hoc change at entrytime. If such a customization is alsoallowed after the processing has started,we name it an on-the-fly change. If evo-lutionary changes are only possible atentry time, only the new cases that arestarted after the change took place haveto run according to the updated workflowdefinition; all other cases run accordingto the old definition. On-the-fly evolu-tionary changes are more difficult to han-dle because for each running workflowinstance, we must decide how to deal withthe change.

Problems to solveAdding flexibility to workflow-man-agement systems is far from trivial.Workflow-management systems suchas Ensemble and InConcert support adhoc workflows, which are defined in anad hoc fashion by the system’s end userbefore execution. Ad hoc workflow-management systems such as Ensem-ble and InConcert replicate the processdefinition for each instance (each casecaries its own private workflow-processmodel). This concept simplifies thehandling of change. However, from amanagement point of view, the repli-cation is less ideal—there is no aggre-gate management information, andrunning cases cannot benefit fromstructural changes without updatingevery private process definition.

The replication mechanism also de-grades system performance. For long-lived workflow processes such as the pro-cessing of mortgage loans (which typicallyhave a life cycle of many years), the repli-cation mechanism is unacceptable: a mort-gage initiated in 1970 would today have anearly 30-year-old workflow-process def-inition. If cases need to be transferred from

an existing process definition to a new one,the use of a replication or versioningmechanism will not suffice. The termdynamic change refers to the problem ofhandling old cases in a new workflow-process definition—how to transfer casesto a new version of the process. We neednew concepts and techniques to avoid theanomalies this problem causes.

WE HAVE MANY predictions for work-flow technology—they are as muchbased on our view of various business orindustry trends as they are on technol-ogy and research trends. The industrieswhere we can first validate our observa-tions are those that are seeing rapidchanges due to deregulation, rapid tech-nology changes, and other reasons. Thebest examples include telecommunica-tions, financial services (including insur-ance), and energy services. The laggardsinclude healthcare and heavy industries,where regulation and legal concernscombined with the slow pace of techno-logical changes and lack of new invest-ments have limited growth or change.We will see the following:

• Workflow-process management func-tions and technology will be absorbedby other technologies. Instead ofstandalone workflow-managementsystems on which workflow applica-tions are built, workflow capability willbe built in critical enterprise applica-tion systems such as ERP and supply-chain management. This capabilitywill be supplied as an integral part of afuture generation of EAI and othermiddleware services. We believe thatprocess management will be necessaryfor products in this area in the nearfuture, just as data access and transac-tion management are critical to mostmiddleware products today.

• Adaptability will become a keyrequirement. This increasinglydynamic environment will lead tovarious kinds of change ranging from

July–September 1999 31

ad hoc modifications for an individualcustomer to evolutionary changes asa result of BPR efforts. Today’sworkflow-management systems haveproblems dealing with change and aretoo rigid to handle the dynamics ofthe networked economy. Therefore,new concepts will need to enableadaptability without losing control.

• Capturing processes will be one of themain outputs of business intelligenceand knowledge management activity.There will be a shift from data-cen-tric to process-centric knowledge.Understanding and managing thedynamics of organized activity will beof prime importance in the new mil-lennium.

• Outsourcing of workflow manage-ment will become an attractiveoption. Currently, corporations al-ready outsource some of their data-related functions as well as their Websites. Recently, new companies aretargeting application outsourcing.For example, rather than managingits own ERP applications, an organi-zation might rent an applicationfrom (and store the data at) an appli-cation service provider and haveaccess to it using a virtual private net-

work or some other means. Organi-zations desire to concentrate on corecompetencies will lead to outsourc-ing process management, especiallyto support interorganizational pro-cesses. Figure 8 illustrates how theoutsourcing of processes will have aconsiderable impact on the way orga-nizations operate.

References1. A. Sheth et al., “Report from the NSF

Workshop on Workflow and ProcessAutomation in Information Systems,” SIG-MOD Record, Vol. 25, No. 4, 1996.

2. S. Jablonski, and C. Bussler, WorkflowManagement: Modeling Concepts, Archi-tecture, and Implementation, Int’l Thom-son Computer Press, Stamford, Conn.,1996.

3. W.M.P. van der Aalst, “The Application ofPetri Nets to Workflow Management,” J.Circuits, Systems and Computers, Vol. 8,No. 1, 1998, pp. 21–66.

4. D. Worah and A. Sheth, “Transactions andin Transactional Workflows,” in Advanced

Transaction Models and Architectures, S.Jojodia and L. Kerschberg, eds., KluwerAcademic, Norwell, Mass., 1997.

Amit Sheth directs the Large-Scale Distrib-uted Information Systems Lab at the Univer-sity of Georgia and is a full professor in theDepartment of Computer Science. He alsofounded and serves as president of InfocosmInc. (http://www.infocosm.com). His techni-cal interests include enterprise integration,semantics in global information systems, dig-ital libraries, e-commerce, and digital media.He received his BE in electrical and elec-tronics engineering from the Birla Instituteof Technology and Science, Pilani, India, andhis MS and PhD in computer and informa-tion technology from Ohio State University.He is a member of the IEEE and ACM. Con-tact him at the LSDIS Lab, Dept. of Com-puter Science, Univ. of Georgia, 415 Gradu-ate Studies Research Ctr., Athens, GA30602-7407; amit@cs.uga.edu; http://lsdis.cs.uga.edu.

Wil van der Aalst is an associate professor inthe Department of Mathematics and Com-puting Science at Eindhoven University ofTechnology. He leads a research group work-ing on software engineering, Petri nets, andworkflow management. He also works for theDutch consulting firm Bakkenist, where heworks on workflow-related projects. Hisresearch interests include simulation and ver-ification of business processes, Petri net the-ory, information systems, and logistics. Con-tact him at the Dept. of Mathematics andComputing Science, Eindhoven Univ. ofTechnology, P.O. Box 513, NL-5600 MB,Eindhoven, The Netherlands; wsinwa@win.tue.nl.

Ismailcem B. Arpinar is a postdoctoralresearch Fellow at the Large-Scale Distrib-uted Information Systems lab at the Univer-sity of Georgia. His primary research workand interests are in the area of database sys-tems, particularly workflow systems, transac-tion processing, electronic commerce, processrepositories, and distributed databases. Hereceived his BS, MS, and PhD degrees incomputer engineering from the Middle EastTechnical University in Ankara, Turkey.Contact him at the LSDIS Lab, Dept. ofComputer Science, Univ. of Georgia, 415Graduate Studies Research Ctr., Athens, GA30602-7407; budak@ainge.cs.uga.edu; http://orion.cs.uga.edu:5080/~budak.

Time

1995 2000 2005

Impact ofoutsourcing

Datarepositories and

warehouses

Enterpriseapplications

Enterprise andinterorganizational

processes

Web site

Figure 8. Outsourcing of data, Web, applications, and processes.