processes driving the networked economy s · networked economy together to deliver products and...

2 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. Usingthe Internet and the Web as the primarycommunications, interoperability, andintegration platform, information systemswill play an increasingly critical role in pro-viding a competitive edge for organiza-tions in the networked economy. So far,most of the attention in Information Sys-tems has gone to data. We believe that thisattention will increasingly shift to infor-mation and knowledge on one hand andprocesses on the other. The first deals withservice and product, the second deals withhow to effectively support or render it.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.Today, workflow technology is the mostimportant software technology that sup-ports and automates organizationalprocesses. The research and technologiesthat make up workflow-process manage-

ment represent tremendous diversity, duein part to the breadth, complexity, andmultidisciplinary nature of the problemsworkflow-process management addresses.1Consequently, compared to contemporarytechnologies such as messaging, databasemanagement, and applications servers, itis both harder to provide comprehensivecoverage to all the issues facing work-flow—a limitation this article admits to—and to build 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

workflow-process

technology will power

the evolution of

information system

architecture. The

authors outline three

likely stages of

architectural evolution

in the context of a

networked economy

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 3

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 around1996, and 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. EnterpriseResource 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 solu-tions (such as telecommunication,healthcare, distribution, transportation,and central and local government).Domain-specific applications such ascall-center packages also reap the fruitsof today’s workflow technology:Lucent’s call-center product usesInConcert 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 virtualcommunities of commercepartners. Current EAI ven-dors—including Vitria andActive Software—areincreasingly adding work-flow capabilities to achievea competitive advantage,while products with rootsin workflow increasingly

add EAI capabilities. New breeds ofproducts, such as EAppS from Infocosm(which is based on the University ofGeorgia’s Meteor), are taking an inte-grated 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: thetelecommunicationsindustry

Arguably 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,and technology breakthroughs. Conse-quently, not just the technology, but alsothe businesses are moving at the “speedof Internet.” In fact the pace of acquisi-tions, mergers, and alliances sometimesseems to outstrip the pace of technolog-ical changes. The high valuations thatWall Street has afforded to new entrantshave fueled entirely new business mod-els, creating a new breed of global cor-porations that in turn have providedopportunities for applying information

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)

4 IEEE Concurrency

technology to solve the challenges. Let’sbriefly review one of the telecommuni-cations industry’s main drivers: conver-gence or next-generation networks. Gener-ally, this refers to any of the stages ofevolution starting from the coexistenceand integration of public-switched tele-phone networks with packet-switcheddata network, to the development anddeployment of a single common packetnetwork for supporting voice, data,video, and other communications ser-vices (including what is termed asVoIP—voice over IP). The business dri-ver for convergence is the compellingcost advantage data networks have overswitched networks and tremendousgrowth rate of Internet data traffic(which doubles 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. Thisincludes local exchange carriers (LECs)that serve local markets (which aredivided into incumbent LECs such asformer “baby Bells” and the newer com-petitive LECs); (b) long distance carri-ers where competition increased withderegulation; Internet Service Providersincluding those supporting traditionalmodem, cable, and xDSL technologies;and wireless service providers. Two ofthe most critical success factors that thishighly competitive industry has identi-fied are customer acquisition and reten-tion, and providing value-added features

and bundled services. Solutions sup-porting these two compelling needsinvariably lead to the need for interor-ganizational workflow because cus-tomers prefer to deal with a single ser-vice provider, and most high-valueservices require integration of what dif-ferent types of providers have to offer.

Architecture forinterorganizationalworkflowsThe 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, workflowsystems 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 businessprocess of a virtual enterprise, alsoknown as interorganizational workflow,goes beyond a single enterprise bound-ary: it is constructed by combining theservices different companies (collectivelycalled a trading community) provide.Some of the fundamental issues toaddress before implementing a virtualenterprise should include how to providea mechanism whereby companies canadvertise their services and how to exe-cute a virtual process that spawns severalenterprises without being managed byone physical enterprise.

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 dynamic 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 portalis responsible for carrying out a majorityof activities using the data it has and thetransactions it supports. Some of thesetransactions might involve applicationswithin the organization to which theportal belongs, and a few might even bewell-defined transactions or informationexchanges with partner organizations(see Figure 1). An information or tradi-

Figure 1. The process portal marketplace architecture.


tional e-commerce portals (where sell-ing packaged products is the key activ-ity) primarily involve application serversand databases. A key characteristic of aportal is for it to own or manage muchof the data and information it needs tomeet customer needs. More advancedportals might use workflow-process sup-port and EAI services to interface withapplications, primarily within a singleorganization. For example, in thetelecommunications industry, applica-tions suited for this architecture includeconsumer-to-business e-commerce ap-plications such as integrated billing andcustomer 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 databaseand transaction oriented e-commerce.Current portals are expected to evolve tohost applications (such as enterpriseresource planning systems) so that acompany can outsource its applicationand data management.

Looking to the future, 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 tradingrules. 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 supplies.These processes might access the entriesof a catalog where the partners within atrading community can post their ser-vices and needs.

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 architecturebecomes relevant in the telecommuni-cations industry when service providersneed to support different classes of cus-tomers (such as individual residences,small businesses, or large businesses) and

require flexibility to deal with a limitedset of partners.

We expect traditional multitier soft-ware architecture 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.

DYNAMIC 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 semi-autonomous 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 be

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

6 IEEE Concurrency

highly 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,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 dynamic trad-ing processes in a virtual marketplace.

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. Here

the 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 networkedeconomy’s requirements in the next mil-lennium and the corresponding archi-tectural alternatives discussed earlier,let’s discuss some of the key technolo-gies or components of workflow-processmanagement along with the problemsthey need 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 areinstantiated for specific cases,3 examplesof which include a request for a mort-gage loan, an insurance claim, a tax dec-laration, or an order for a new telecom-munications 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 asresponsibility 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 workflow type)is the specification of a workflow thatcovers all these aspects. Cases areinstances of a workflow type and are han-dled accordingly. A workflow-management

Figure 3. Dynamic trading processes.


system aims at supporting the five per-spectives shown in Figure 4. The build-time service of the workflow-manage-ment system allows for the specificationof 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 Meteor builder.The workflow-process definition con-sists of 13 tasks and specifies the pro-cessing of travel requests. Conditionalarcs model the causal relations betweentasks. The routing conditions depend oncontrol data specified in the informationperspective. Meteor supports the explicitmodeling of the workflow perspective,but most workflow-management sys-tems do not have such a facility: theinformation perspectives (and the oper-ation perspective) are modeled implic-itly as extensions of the workflow-process definition. The only perspectivethat is typically modeled in separate dia-grams is the organization perspective.

Lack of adequate standards forworkflow modelingIn the last decade, many languages havebeen proposed for the modeling of work-flow-process definitions. In fact, in theearly 1970s researchers worked on tech-niques for the modeling of office proce-dures. Most workflow-management sys-tems use a graphical design languagewhere tasks are connected by arrows androuting elements. Despite the efforts ofstandardization bodies such as the Work-

flow Management Coalition (WfMC),there is no real consensus on the repre-sentation of workflow processes. Stan-dards such as Interface 1 of the WfMCand PIF (Process Interchange Format)focus on the syntax of the modeling lan-guage rather than support specificationsor descriptions of process semantics. PIFis an 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. As aresult, their use was boosted.

Until now, such a formal basis is miss-ing from the workflow domain. Manyresearchers advocate the use of Petri netsas a formal basis for workflow modeling.The Petri net formalism combines a

strong mathematical foundation with anintuitive graphical representation. Sev-eral workflow-management systems usea modeling language based on Petri nets(such as COSA, INCOME, BaanERP,and SAP R/3). However, most workflowsystems use a vendor-specific diagram-ming language. These diagramming lan-guages typically abstract from states anddo not allow for advanced routing con-structs involving a mixture of choice andsynchronization. As a result of these andother limitations, it is difficult to trans-late a workflow-process definition fromone system to another. For the organi-zation perspective, there are even fewerconsensuses. Some workflow-manage-ment systems use a simple role-basedmechanism in which there is one workqueue for each role. Other systems (suchas COSA) provide an advanced scriptinglanguage with multiple allocationdimensions 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,

Figure 5. Workflow-process definition.

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

8 IEEE Concurrency

a customer would be outside of an orga-nizational model, but customers willincreasingly track orders over the Webusing the same software as employees.Furthermore, in future e-commerceapplications, the customer will be able toinfluence the underlying workflowprocess by updating requests or supply-ing additional information. This willrequire new paradigms to design andmanage the organization perspectiveaccurately and effectively.

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 haveproblems dealing with situations involv-ing a mixture of synchronization andchoice. In fact, the majority of work-flow-management systems use a designlanguage that corresponds to the so-called class of free-choice Petri nets.3 Itis well-known that the expressive powerof this class is limited compared to stan-dard Petri 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 ERP

systems offer hundreds of readymadeworkflow templates (often called businessor reference models) that can be used asa 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 andthat 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 onquantitative measures such as averageorder lead time, percentage of cases han-dled within a week, number of cases inprogress, and utilization of bottleneckedresources. Today’s workflow-manage-ment systems give limited support toperformance analysis—they provide arudimentary simulator or a gateway to asimulation tool. Simulation can estimatekey performance indicators by experi-menting with the specified workflowunder an assumed specific environmen-tal behavior. Most workflow-manage-ment systems do not give any support forworkflow verification. As a result, work-flow-process definitions become opera-tional before they are thoroughlychecked for correctness. This oftenresults 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 millions ofstates.

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, informalbusiness 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 Con-

firmApproval2 has been executed with apositive result). This workflow deadlocksif 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 ReserveTick-ets2 is still there, resulting in a danglingreference to a case that does not existanymore. Figure 6 shows the diagnosticsthe workflow-verification tool Woflanprovided that indicate the error’s source.The workflow-process definition madewith Meteor was imported by Woflan,which automatically translated theprocess 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-

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

10 IEEE Concurrency

tive, the added value of good verificationfacilities is considerable.

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 tra-ditional approach toward simulationdoes not work for this purpose becauseit focuses on strategic decisions withlong-term effects. Research effortsshould aim at simulation facilities that

are concerned with the effects of a deci-sion in the near future and exploit all theinformation available including theactual current state. Such facilities canprovide managers with a kind of fast-forward button. By pushing this button,we can see the current situation extrap-olated. We can also see the effect of cer-tain decisions (for example, hiring addi-tional employees or renouncing neworders) in the near future. Advancedanalysis capabilities for verification, val-idation, and performance analysis willgive managers the tools to reactpromptly to the ever-increasing pace ofchange. The applicability of the nextgeneration of workflow-managementsystems 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 existing

workflow-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 fordynamic trading processes and for mak-ing the process management organic andintegral to the systems that will supportapplications in a networked economy.Figure 7 shows an evolution in the archi-tecture of workflow-enactment services.

Two examples of fully distributedenactment services are the ORBWorkand WebWork components of theMeteor system and its commercial ver-sion, EAppS. WebWork relies only onthe 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 task

Workfow-1Process definition

http://process-definition-URI

CREATEPROCESSINSTANCE

ProcessinstanceURI Create

SUNSCRIBE

NOTIFY/COMPLETE

Observer



CreateActivity

observer



CREATEPROCESSINSTANCE

ProcessinstanceURI Create

SUNSCRIBE

NOTIFY/COMPLETE



CreateActivity

observer

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


managers. 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’shighly 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 frameworkfor 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, Con-sistency, Isolation, Durability) transac-tions, adequate solutions for transac-tional support in workflow systems arestill missing.

The term transactional workflow wasintroduced in 1993 and further elabo-rated onl 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 to

respond 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 systemsmainly rely on the database environment’srecovery capability, or users are forced togo 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) techniquesdetect 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 economyrequires a powerful and reliable execu-tion environment to enact businessprocesses that can span the boundariesof multiple organizations. Significantadditional research and serious engi-neering efforts are needed to improvescalability, exception handling, auto-matic recovery, and other 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 with

12 IEEE Concurrency

Java 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-man-agement systems still have a long path

ahead before they will effectively addressQoS issues.

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 can

apply to external parties such as vendors,other businesses, and customers. Toachieve wide-scale interoperabilitybetween organizations, cooperationbetween 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.

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.ent-

mag.com.

PRELUDE TO THE NETWORKED ECONOMY: THE

TELECOMMUNICATIONS INDUSTRYG. Lenahan. “A Practical View of Network Evolution,” Next Genera-

tion Networks, 1998; http://www.telcordia.com..

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

Readings in electronic marketplace architecturesG. Alonso et al., “WISE: Business to Business E-Commerce,” IEEE Ninth

Int’l Workshop on Res. Issues on Data Engineering, IEEE ComputerSoc. Press, Los Alamitos, Calif., 1999.

S. Arpinar, A. Dogac, and N. Tatbul, “An Open Electronic Marketplacethrough Agent-based Workflows: MOPPET,” Int’l J., to appearlate 1999.

Commerce One, Enabling the Business-to-Business Trading Web UsingmarketSite 3.0 Open Marketplace Platform, Commerce One, NewYork, Mar. 1999.

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

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

The Ontology Group, Reference Architecture for iMarkets, Part 1Overview. Draft 1.1, Ontology.org, Sep. 1998; http:www.ontol-ogy.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,” in Information and Process Inte-gration in Enterprises: Rethinking Documents, T. Wakayama etal., eds., Kluwer Academic Publishers, Norwell, Mass. 1998, pp.161-182.

C.A. Ellis, and G.J. Nutt, “Modelling and Enactment of Workflow Sys-tems,” in Application and Theory of Petri Nets 1993, M. AjmoneMarsan, ed., Springer-Verlag, Berlin, 1993, pp. 1-16.

PIF Working Group, PIF: The Process Interchange Format v.1.2, PIF

Working Group, Dec. 1997, //au: Web site or publisher loca-tion?//.

WfMC-TC-1016-P, Interface 1: Process Definition Interchange ProcessModel, Workflow Management Coalition, http://www.aiim.org/wfmc, Nov. 1998.

M.D. Zisman, Representation, Specification and Automation of OfficeProcedures, PhD thesis, Univ. of Pennsylvania, Warton School ofBusiness, 1977.

Verification of workflow process definitionsW.M.P. van der Aalst, “Verification of Workflow Nets,” Application

and Theory of Petri Nets 1997, in P. Azema and G. Balbo, eds.,Springer-Verlag, Berlin, 1997, pp. 407-426.

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

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

M. Voorhoeve, “Modeling and Verification of Workflow Nets,” inWorkflow Management: Net-based Concepts, Models, Techniquesand Tools (WFM’98), W.M.P. van der Aalst, G. De Michelis, andC.A. Ellis, eds, //au: who published this?//, 1998, pp. 96-108.

QoS: Achilles’ Heel of workflow managementI.B. Arpinar et al., “Formalization of Workflows and Correctness Issues

in the Presence of Concurrency,” Int’l J. Distributed and ParallelDatabases, Vol. 7, No. 2, April 1999.

D. Barbara et al., “INCAs: Managing Dynamic Workflows in Distrib-uted Environments,” J. Database Man., Winter 1996, //Volume?Number? Pages?//.

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 Man-agement,” Proc. of RIDE, //au: who published this? Where?What pages?// 1997.

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

C. Hagen and G. Alonso, “Flexible Exception Handling in the OPERA


SpecificationsIn general, we can classify interoperabil-ity specifications for workflow systemsinto two categories: specifications formodeling and workflow description, andspecifications 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 support

exchanging 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 createinstances of the particular process type andoperations to report a workflow instance’sstatus changes. Once a workflow systemsupports these interfaces, it can talk withother workflow products by exchangingprocess control and status informationthrough common operations.

The WfMC Interface 4 specification,published in 1998, lets workflow systemsfrom multiple vendors interoperate withone another. It defines the mechanismsthat workflow product vendors are

required to implement for one workflowengine to make requests of another. InApril 1999, WfMC announced that sev-eral vendors had developed the firstWfMC Interface 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 workflowapplications 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 Facility

Process Support System, Proc. 18th Int’l Conf. on Distributed Com-puting Systems, //au: who published this? Where? Whatpages?//, 1998.

M. Huhns and M. Singh, “Multiagent Systems in Information-Rich Envi-ronments,” Proc. of Second Int’l Workshop on Coop. Info. 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,Dynamic Systems,” Component Strategies, March 1999 //au: isthis a journal? What volume, number, month? Pages?//.

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

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

S. Wheater et al., “A CORBA Compliant Transactional Workflow Systemfor Internet Applications,” Proc. of the IFIP Int’l Conf. on Distrib-uted System Platforms and Open Distributed Processing, //au:who published this? Where? What pages?// 1998.

D. Worah and A. Sheth, “Transactions and in Transactional Workflows,”in Advanced Transaction Models and Architectures, S. Jojodia andL. Kerschberg, eds., Kluwer Academic, Norwell, Mass., 1997.

D. Wodtke et al., “The MENTOR Workbench for Enterprise-wide Work-flow Management,” Proc. ACM SIGMOD Int’l Conf. on Manage-ment of Data, ///au: who published? Where? Pages?// 1997.

Workflow interoperability specificationsM. Anderson and R. Allen, Workflow Interoperability: Enabling E-Com-

merce, White Paper, http://www.aiim.org, April 1999.

F. Casati et al., “Semantic WorkfFlow Interoperability,” Proc. of EDBTConf., //who published, where, what pages?//, 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, April 1998.

SWAP Working Group, Requirements for Simple Workflow Access Pro-tocol, Internet Draft, SWAP Working Group, http://www.ics.uci.edu /~ietfswap/, Nov. 1998.

Research on adaptabilityW.M.P. van der Aalst et al., “Adaptive Workflow: On the Interplay

Between Flexibility and Support,” Proc. ICEIS, //au: who pub-lished? Where?//, 1999, pp. 353-360.

A. Sheth, “From Contemporary Workflow Process Automation to Adap-tive Dynamic Work Activity Coordination and Collaboration,”Proc. Workshop on Workflows in Scientific and Engineering Appli-cations, //au: publisher? Location? Pages?//, 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 within Work-flow Systems,” in Proc. Conf. on 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-98 Work-shop Towards Adaptive Workflow Systems, //au: publisher? Pub.Location? Pages?//, 1998.

M. Reichert and P. Dadam, “ADEPTflex: Supporting Dynamic Changesof Workflow without Loosing Control,” J. Intelligent InformationSystems, Vol. 10, No. 2, 1998, pp. 93-129.

M. Wolf and U. Reimer, eds., Proc. Int’l Conf. Practical Aspects of Knowl-edge Management (PAKM’96), Workshop on Adaptive Workflow,//au: who published, where?//, 1996.

GeneralA. Dogac et al., eds., “Workflow Management Systems and Interoper-

ability,” NATO ASI Series, Springer-Verlag, Berlin, 1998.

D. Georgakopoulos, M. Hornick, and A. Sheth, “An Overview of Work-flow Management: From Process Modeling to Workflow Automa-tion Infrastructure,” Distributed and Parallel Databases, Vol. 3,1995, pp. 119-153.

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

P. Lawrence, ed., Workflow Handbook 1997, Workflow ManagementCoalition, John Wiley & Sons, New York, 1997.

R.M. Lee, “Distributed Electronic Trade Scenarios: Representation,Design, Prototyping,” J. Electronic Commerce, Vol. 3, No. 1, 1999.

The Ontology Group, The Need for a Shared Ontology: Business Seman-tics Underpin XML-Based Architectures, The Ontology Group,White Paper, http://www.ontology.org, 1999.

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

14 IEEE Concurrency

RFP in 1998. jointFlow addresses therequirements for interoperability betweendifferent workflow-system implementa-tions in a CORBA environment.

Open IssuesAlthough some standardization

efforts are under development, interop-erability specifications are still far frommeeting the interoperability needs ofworkflow systems, especially those thatoperate in a virtual business environ-ment. Most runtime interoperabilitystandards make assumptions about themiddleware or implementation infra-structures. With multiple organizationsparticipating, the only common groundto be expected is the Internet (HTTP,XML, and possibly Java). Hence theinteroperability solutions need to evolvetoward multiprotocol and more hetero-geneous middleware 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-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 version ofthe preferred process. However, the realruntime process is often much more vari-able than the process specified at designtime. The only way to handle changes isto go behind the system’s back. If users

are forced to bypass the workflow-man-agement system quite frequently, the sys-tem is more a liability 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. Thechange 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, then only the new cases thatare started after the change took placehave to run according to the updatedworkflow definition; all other cases runaccording to the old definition. On-the-

fly evolutionary changes are more diffi-cult to handle because for each runningworkflow instance, we must decide howto deal with the change.

Problems to solveAdding flexibility to workflow-manage-ment systems is far from trivial. Work-flow-management systems such asEnsemble and InConcert support ad hocworkflows, which are defined in an adhoc fashion by the system’s end userbefore execution. Ad hoc workflow-man-agement systems such as Ensemble andInConcert replicate the process defini-tion for each instance (each case caries itsown private workflow-process model).This concept simplifies the handling ofchange. However, from a managementpoint of view, the replication is lessideal—there is no aggregate managementinformation, and running cases cannotbenefit from structural changes withoutupdating every private process definition.

The replication mechanism alsodegrades 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 froman 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 industrieswhere regulation and legal concernscombined with the slow pace of techno-logical changes and lack of new invest-ments have limited retarded growth orchange. We will see the following:

• Workflow-process managementfunctions and technology will beabsorbed by other technologies.Instead of standalone workflow-man-agement systems on which workflowapplications are built, workflow capa-bility will be built in critical enter-prise application systems such as ERPand supply-chain management. Thiscapability will be supplied as an inte-gral part of a future generation of EAIand other middleware services. Webelieve that process management willbe necessary for products in this areain the near future, just as data accessand transaction management are crit-ical to most middleware productstoday.

• Adaptability will become a keyrequirement. This increasinglydynamic environment will lead tovarious kinds of change ranging fromad 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 managementwill become an attractive option. Cur-rently, corporations already outsourcesome of their data-related functions aswell as their Web sites. Recently, newcompanies are targeting application

outsourcing. For example, rather thanmanaging its own ERP applications,an organization might rent an applica-tion from (and store the data at) anapplication service provider and haveaccess to it using a virtual private net-work or some other means. Organiza-tions desire to concentrate on corecompetencies will lead to outsourcingprocess management, especially tosupport interorganizational processes.Figure 8 illustrates how the outsourc-ing of processes will have a consider-able impact on the way organizationsoperate.

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.

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; [email protected]; 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; [email protected].

Ismailcem B. Arpinar is a post-doctoralresearch 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; [email protected]; http://orion.cs.uga.edu:5080/~budak.

Data repositoriesand warehouses

Impact of outsourcing

Time




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