supporting optimization of business-to-business e-commerce ... · supporting optimization of...

Ž .Decision Support Systems 31 2001 363–377www.elsevier.comrlocaterdsw

Supporting optimization of business-to-business e-commercerelationships

William Kuechler Jr. a,), Vijay K. Vaishnavi b, David Kuechler b

a Department of Accounting and Computer Information Systems, UniÕersity of NeÕada at Reno, Reno, NV 89557, USAb Department of Computer Information Systems, Georgia State UniÕersity, Atlanta, GA, USA

Abstract

Much current e-commerce subscribes to very simple interaction models. Many of the potentialities of e-commerce areidentical to those that have been under study for some time in the field of automated workflow management systems. In this

( )paper, we describe a new workflow interoperability model, the monitored–nested model MNM , and show that it cansupport optimized, extended e-commerce transactions that are not supported by current models.

Like other interoperability models, MNM is dependent on process activities, and thus is brittle under real-worldconditions of process evolution. This is overcome by augmenting the model with goal-based meta-data and the use of acoordination inferencing algorithm. q 2001 Elsevier Science B.V. All rights reserved.

Keywords: Workflow; E-commerce; E-business; Inter-organizational systems

1. Introduction

Recent studies by technology consulting groupspredict more than one fourth of all business to

Ž .business B2B purchases will be transacted on theInternet by 2004—a dollar volume 10 times that ofInternet consumer purchases. The explosion in Inter-net-based B2B is driven by economics—the Internetoffers the potential for reduced prices for goods andreduced transaction costs, but this is not simplyderived from the Internet as a communications in-

Ž .frastructure. The capability for relatively inexpen-sive electronic B2B communications has existed forsome time in highly evolved form, as witnessed by

) Corresponding author.Ž .E-mail addresses: [email protected] W. Kuechler ,

Ž [email protected] V.K. Vaishnavi , [email protected]Ž .D. Kuechler .

EDI. Newer, Internet based e-marketplaces as theyare currently conceived overcome some of the prob-lems encountered with traditional EDI, and constituteessentially a better–cheaper-EDI.

As business-to-business e-commerce moves closerto its full potential, it will progress beyond abetter–cheaper-EDI to the support of business rela-tionships that match or exceed the dimensionality ofnon-electronic relationships. However, support andoptimization of such relationships require more so-phisticated models of interaction than those currentlyin use.

1.1. Beyond EDI to online trading communities

Traditional EDI is a one-to-one technology: buyerand seller must locate each other and then performsubstantial work to link their systems. The new

0167-9236r01r$ - see front matter q 2001 Elsevier Science B.V. All rights reserved.Ž .PII: S0167-9236 00 00142-1

( )W. Kuechler et al.rDecision Support Systems 31 2001 363–377364

Internet-based online trading communities, such asw x w x w xAriba 1 , i2 7 , and CommerceOne 3 , in addition

to enabling B2B transactions so facilely that theyhave been termed e-commerce vending machinesw x12 , are true markets. Within each community, anontology—common business processes and elec-tronic documents including product definitions and

Ž .pricing—is defined in a standard language XMLand published for universal access. Product offeringsand prices from multiple suppliers can be electroni-cally scanned and processed at very low error ratesleading to predictions of billions of dollars per yearin procurement cost savings.

1.2. ImproÕing online trading communities

The efficiency of many operations in e-commercetransactions is less than optimal because they operatefrom Õery simple relationship models. Essentially,current online trading communities automate the mostbasic order–receiÕe–pay scenario:

v The purchaser electronically scans the marketplaceand chooses a product

v The price, quantity and a delivery date are agreedupon using standardized XML-described orderdocuments.

v An electronic invoice is sent from supplier toŽ .purchaser at or about the time of delivery

v The purchaser schedules automated payment onconfirmation of delivery

Notice that there is no proÕision in this scenariofor multi-party transactions and no proÕision forexceptions. As e-commerce matures, we believe on-line trading partner relationships will rapidly push

toward the sophistication and complexity found innon-automated business relationships, which are de-sirable precisely for their ability to integrate theefforts of multiple legally independent entities whileaccommodating exceptions and changes.

In the basic order–receive–pay scenario, transac-tions between companies are considered to be atomic,that is, no detail on the execution of the transactionis available. The lack of detail makes it impossiblefor companies to interact with the richness that cur-rent manual relationships possess. For example, de-lays in production are hidden until the delivery dateis exceeded. Or, changes in specification that appearminor to one party but are significant to anotherremain unknown until the delivered product is closelyinspected, possibly on the assembly line floor!

1.3. Workflow management system concepts and e-commerce

Ž .Workflow management systems WfMS are soft-ware systems that facilitate, augment and sometimes

Žcontrol the flow of work within and for our pur-.poses especially between organizations. As interor-

ganizational WfMS become increasingly commonand as the interaction between WfMS becomes in-creasingly web-based, much automated workflow en-actment becomes by definition electronic commercew x22 .

The notion that automated business processes,executed oÕer the Internet between multiple organi-zations, are the future of electronic commerce is atthe core of the visions of authors from many fields.It also figures prominently in the literature of manycommercial Internet marketplace-hosting organiza-

Ž . w xtions see Fig. 1 . According to Sheth et al. 17 ,

Fig. 1. Commercial e-commerce service providers view of interorganizational workflow. A composite view taken directly from thew xmarketing literature of commercial e-marketplace hosting organizations 1,3,7 .

( )W. Kuechler et al.rDecision Support Systems 31 2001 363–377 365

A . . . we see processes as an organic component ofany enterprise application integration or e-commercesolution. In this sense, workflow-process technologywill conduct the emerging networked economy from

w xbehind the scenes.B Jain et al. 8 see agent enactedworkflows and a form of intention-driven e-com-merce transaction similar to the one presented in thispaper as the enabling technology for virtual corpora-tions. These visions propose workflow-as-e-com-merce in the near future since by definition theautomation of formal process definitions is work-flow management. Charles Petrie, executive directorof the Stanford Networking Research Center, writingwith Sunhil Sarin, a commercial WfMS developerand researcher, state the case even more strongly:AInternet mediated workflow will be the most impor-

w xtant technology of the early 21st centuryB 14 .We propose that many of the problems and poten-

tialities that exist for e-commerce are exactly thosethat have been under research for some time ininter-organizational WfMS. Workflow interoperabil-ity models provide the foundation for the study ofrelationships between autonomous workflows andfor the technology to model and enact such relation-ships.

2. Workflow interoperability models and businessscenarios

Although they are not complex, workflow inter-operability models are best discussed in relation tobusiness scenarios that give depth and concretenessto the concepts. This is the approach taken by theWorkflow Management Coalition, an internationalgroup of commercial WfMS producers and WfMS

researchers. The order fulfillment example given hereŽ .see Fig. 2 is a minor variation on a benchmark usedin Workflow Management Coalition documents togive a standard for comparisons. The example issimple, but is capable of illustrating most points thatarise in far more complex real world interactions.We will later expand this example to illustrate de-sired optimizations of B2B e-commerce relationshipsthat go beyond the order–receive–pay model im-plicit in EDI type interaction. We propose two ex-pansions of the base scenario as part of a benchmarksuite for extended WfMS interoperability.

In the base scenario illustrated in Fig. 2, allparticipants are assumed to have a WfMS. Retailersells an item of furniture that must be custom-madeand drop-shipped from Manufacturer. Manufactureris responsible for contracting for shipping the item tocustomer. Each column of the figure represents theprogression of high-level tasks required for that por-tion of order fulfillment processing required of eachof the cooperating business entities. The high-leveltasks, such as Schedule Production may be instanti-ated in the Manufacturer’s workflow by a series oflower-level activities that accomplish the higher-leveltask; this detail has been omitted for clarity. Eachentity’s tasks are interleaved, taking place in parallel.The events proceed in the conventional WFMC sce-nario as they have been numbered in Fig. 2, from 1to 10. The shaded segment of the figure depicts theoptimized workflow discussed below.

For even the base scenario to proceed, the WfMSin each of the cooperating organizations require in-formation on:

1. the location of contractors on which it dependsŽ .interoperates

Fig. 2. Basic and optimized order fulfillment via interoperating processes.


Ž2. a format for the communications requests for.service that will be understood by the other

WfMS3. how the workflow that is requesting service is to

behave during the performance of service4. an expectation of and format for a return commu-

Ž .nication s indicating various states of the re-Ž .quested service s .

Information items 2, 3, and 4 can be abstracted to aworkflow interoperability model; reference to com-mon interoperability models will be useful in dis-cussing improvements to the ordering process. TheWorkflow Management Coalition defines three inter-operability models in its interoperability documentw x21 : chained interoperating processes, nested inter-operating processes, and parallel-synchronized in-

Ž .teroperating processes see Fig. 3 .The Chained Interoperability Model is the least

complex in that it requires a WfMS to possess theleast information about cooperating WfMS. Chained

Ž .processes or subprocesses are invoked by oneWfMS in another WfMS and no further interactiontakes place with the subprocess. In Workflow Man-agement Coalition terms, they are ‘trusted’ processesand delegation to them is total. Chained processes

Žare defined in WPDL the Workflow Management

.Coalition’s process description language as activi-ties whose type is subprocess and whose executionmode is asynchronous.

In a Nested Interoperability Model, once the callis made by a process to a subprocess, the callingprocess suspends operations until the subprocesscompletes. Nested subprocesses are defined in WPDLas activities whose type is subprocess and whoseexecution mode is synchronous. Note that sinceWPDL supports multiple threads in a workflow, theoverall workflow that issues the nested subprocesscall need not suspend; only the calling thread sus-pends. Nesting may recurse.

In the parallel-synchronized InteroperabilityModel, workflows run in parallel on different WfMSand are required to achieve periodic synchronizationpoints. Parallel-synchronized interoperability hasbeen designated by the Workflow ManagementCoalition as outside the scope of their current inter-operability specifications. This is due to the com-plexity involved in generalizing this type of interac-tion between systems, and its lack of robustnessunder activity changes, a problem detailed in Section4.

The workflow interaction in the order fulfillmentscenario is modeled by the nested interoperabilitymodel. Nested subprocesses correspond exactly in

Fig. 3. Workflow interoperability models.


the example to the calls for service from the Retailerto the Manufacturer and from the Manufacturer toShipper.

2.1. Optimizing B2B relationships: proposal for abenchmark scenario

As presented in WFMC literature the order fulfill-ment scenario requires confirmation from both Ship-per and Manufacturer before the Retailer invoicesthe client. Suppose, however, that Shipper’s perfor-mance became predictable. A desirable optimization

Žunder such conditions one first widely demonstrated.by the Japanese would be to use that predictability

to decrease the overall business cycle time by invoic-ing the client at an earlier point—say when theshipping of the item was scheduled—to improvecash flow. However, the invoice must come from theRetailer, and using simple nested interaction, theRetailer is two levels removed from the informationrequired. That is, the Retailer invoked the Manufac-turer’s process and has no information on that pro-cess state until it completes. The Manufacturer’sprocess invoked the Shipper’s process, and has noinformation on that process state till it completes.There are thus two levels of isolation using thenested workflow interoperability model from the in-formation required to optimize the overall process.

The suggested improvement in overall workflowis shown in the shaded section of Fig. 2. The dashedarrow from activity 5 Manufacturer’s Schedule Ship-ping directly to Retailer’s activity 10 InÕoice Cus-tomer graphically illustrates this modification. In-voicing under the optimized scenario takes placeprior to activities 6 through 9 in the original sce-nario. This scenario constitutes the first of our pro-posed suite of scenarios for extended WfMS interop-

erability; the second scenario is described in Section5.

The suggested optimization, however, requires amore sophisticated interaction model than any exist-ing interoperability model. A key functionality of therequired model is that the processes of cooperatingbusiness partners be at least partially visible to eachother. This allows each cooperating business partnerto modify its processes, including the initiation tim-ing of all of its activities and all other externalworkflows for which it is responsible, in an optimalmanner.

3. Monitored–nested interoperability model

A slight increase in conceptual complexity oversimple nested processes confers considerable poten-

Žtial for flexibility and optimizability of WfMS Fig..4 . We call this new interoperability model the moni-

Ž .tored–nested model MNM ; in it the tasks of thecalling activity have been expanded to include moni-toring the state of the subprocess it has invoked, andthe initiation of new process activity in its ownworkflow environment when a monitored subprocessstate has been reached. Implementation of the activ-ity initiation portion of the new model can be asimple Java-like event registration:

Ž .a the monitored state in workflow B is registeredwith B and as a precondition for a workflowactivity in AŽ .b on achievement of state, a message is sentfrom B to A

The simple nested model is a limited special case ofthe monitored–nested model in which the only con-

Fig. 4. Monitored–nested interoperability model.


dition monitored by workflow engine A is the endpoint of the task invoked by A in workflow engineB. The monitored–nested model is similar to theparallel-synchronized model in that the synchroniza-tion points of the parallel-synchronized model maybe considered equivalent to monitored state commu-nications. The models are different in that in theparallel-synchronized model workflow engine A isnot responsible for initiating the workflow in work-flow engine B. Moreover, synchronization communi-cations do not explicitly initiate other workflowthreads as state communications between workflowsdo in the monitored–nested model. Finally, in bothof the nested models, activity in the workflow threadin engine A that initiated the external workflowsuspends for the duration of the invoked activitywhereas in the parallel-synchronized model activitiesproceed continuously in both workflows.

3.1. Use and benefits of MNM

According to information-processing-based orga-w xnization theory 5 , certain forms of organizational

Ž .structure or in this case, transaction structureemerge whenever multiple tasks involving uncer-tainty must be coordinated efficiently. A commonname for one frequently observed such form is thecontractor–subcontractor relationship in which acomplex process is accomplished by multiple entitiesŽ .the subcontractors under the monitoring and super-vision of an entity responsible for the overall resultŽ .the contractor . This situation is ubiquitous in busi-ness; entire industries are currently based on thecontractor–subcontractor relation, which is formally

modeled by the MNM model. The construction in-dustry is prototypical; different aspects of construc-tion are handled by specialized subcontractors work-

Ž .ing under the supervision monitoring of a generalcontractor. Airplanes, missiles, ships, large softwaresystems and many other complex, assembled prod-ucts are constructed using this coordination model.

The primary benefit of MNM type transactionsover simple nested task interoperation is efficiencyin the face of high natural and unavoidable variabil-ity in the completion times for the individual activi-ties that comprise the workflow. By monitoring thestatus of activities, as the uncertainty of those activi-ties becomes progressively lower, it is possible tocontinuously re-plan the overall process and opti-mize the result relative to simply waiting for eachactivity to complete.

An example of MNM type transactions in currentŽ .business practice though established ‘manually’ is

Ž .the much cited Wal-Mart WM rProctor & GambleŽ .P&G alliance. In this example, status informationfrom WM’s normal inventory and procurementworkflow is opened to its trading partner, P&G.P&G actively monitors sales information in WM’ssystem and this information triggers in P&G’s pro-duction and supply workflow the ordering, and ac-tual restocking on WM’s shelves, of P&G products.The interaction is illustrated in Fig. 5.

3.2. Implementation problems and solutions

The problems involved in the actual implementa-tion of workflow-based B2B e-commerce transac-tions and specifically MNM type transactions derive

Fig. 5. MNM optimized trasaction: Procter & Gamble monitors Wal-Mart’s sales-tracking workflow.


from the difficulty in coordinating WfMS from dif-ferent manufacturers. Like many coordination prob-lems, these are communications problems derivedfrom differences in WfMS architectures, processmodels, communication protocols, and so on. In theworkflow community all such problems fall underthe heading of interoperability: the ability of hetero-geneous WfMS to work together to monitor, coordi-nate and to some degree, control each other inworking toward a common goal.

Much recent research on workflow managementsystems from both universities and WfMS manufac-turers has been focused on interoperability. Thisresearch has been quite successful and practical solu-tions have been found for many early interoperabilityproblems. The problems that have been solved, thosecurrently under research and those raised by theMNM interoperability model presented in this paperare best understood with reference to a protocol

Ž .stack model see Fig. 6 . The model partitions inter-operability issues into levels of abstraction. At eachlevel of the stack above the physical, incompatibili-ties at one level are overcome by meta-level informa-tion supplied by the next higher level.

Physical and communications level interoperabil-ity issues have been effectively solved by standard-ization on the WWW as the communications infras-tructure and low level communications protocol setŽ .TCPrIP and HTTP . Early efforts at linking WfMSengines, the next higher level of abstraction in coor-dinating workflows, were directed at a standardizedAPI’s for the engines. Many of these efforts were

Ž .based initially on remote procedure call RPC syn-tax and later on CORBA and IIOP standards. How-ever, these direct and closely coupled enactmentengine links have been largely superseded by higherlevel XML based protocols—effectively, high levellanguages by which one WfMS may request servicesof another. Specifically, the interoperability prob-lems introduced by different WfMS software archi-tectures are overcome by Wf-XML, a high levelprotocol proposed for standardization by the WfMC.

However, Wf-XML assumes a single process def-inition is shared by coordinating agents. When thisassumption is violated, that is, when processes changedynamically and autonomously, then interoperability

Žproblems arise at the level of process definition see.Fig. 6 . Several solutions to interoperability prob-

w xFig. 6. WfMS interoperability layers 19 .


w xlems at this level have been proposed 10,15,20 ,each aimed at solving a different portion of thebroader issue. What all solutions implicitly share isthe notion that the process definition language mustbe augmented with additional information to supportdynamic modification. In our research, informationon process intention is used to support robust MNMinteroperability; MNM thus remains a researchmodel, currently implemented only in our prototype,pending widespread adoption of a solution to thedynamic process change problem. However, theubiquity of the model in manual commercial transac-tions argues strongly for its adoption into workflowenabled e-commerce once remaining implementationproblems are solved. In the next section, the problemof dynamically changing processes is presented indetail to facilitate a discussion of our solution to theproblem.

4. The dynamic process evolution problem

The monitored–nested interoperability model caneasily support the desired transaction optimizationswe have suggested for the order fulfillment examplediscussed above. Since all activities in subordinateworkflows are visible to Retailer, sufficient informa-tion is available to optimize the overall process.There is, however, a significant practical problem

Žwith the deployment of the model or any model.dependent on process states : it is brittle under real

world conditions of dynamic process evolution. Thelogic to illustrate this is straightforward:

v The monitored–nested model depends on knowingthe states of processes

v The state of a process in a WfMS is inevitablylinked to specific activities

v But the processes being monitored take place out-side the control of the monitoring agent and maychange at any time

v And when an activity is changed, even to a simpleequivalent activity, WfMS do not have sufficient

Žinformation to link the monitored state what is.important to the new activity.

Relative to our example, the Manufacturer and theShipper are autonomous and may change suppliers

Ž .and internal operations activities at any time for avariety of beneficial and necessary reasons. In Fig. 2,the optimization of early inÕoicing is dependent onRetailer receiving notice that shipment of the producthas been scheduled. The completion of ScheduleShipping is effectively a high-level process state,which can be satisfied in any number of ways. In thespecific workflow being used, however, the state islinked to the specific actiÕity Schedule UPS pickup.

Ž .Now suppose that Regional Shippers RSI offers theManufacturer a better price on shipping its goods.The specific activity in the workflow that indicates

w xthe state completion of Schedule Shipping nowbecomes Schedule RSI pickup. Due to the lack ofknowledge about work processes inherent in mostWfMS, this simple replacement of one activity by anequivalent is sufficient to confuse the monitoring onwhich the optimized process coordination depends—the state communication between workflow engineswill never be sent. Of course, in the general case, thechanges to a work process can be much more com-plex than the simple substitution of an activity.

The interrupted coordination will undoubtedly bebrought to human notice eventually. Likewise, coor-dination can be reestablished through human inter-vention—specifically, by reprogramming the system

Žto link the state achievement notification called a.trigger in WfMS terms to the new activity. How-

ever, the driving intention behind e-commerce is toautomate transactions to the highest degree possible.A more ideal situation would be to incorporate intothe WfMS the ability to:

1. link triggers to high-level states of the process2. have the system recognize which activities corre-

spond to achievement of the high-level states,even when activities are changed.

Naturally such automatic adjustment would be sub-ject to human approval, but given a sufficiently highreliability for such a system, human interventioncould be minimal and coordination-cost savings ofthe overall system significant. We have developed atechnique for automating the re-coordination of ac-tivity-based process state notification under processchange that makes use of goal meta-data about theprocess.


4.1. HOPI and goal based meta-data for processes

Conventional workflow management systems con-tain no information about their processes other thanw x11 :

v The activityv Ž .The role actor type required to perform the activ-

ityv Resources needed to perform the activityv Precedence information, frequently in the form of

pre and post conditions for the activity

The monitored–nested model requires more informa-tion about the process than that shown in the abovelist since the activities may change at any time. Theflexibility we seek for the monitored–nested modelis enabled by meta-data, essentially data about data,which can be used by systems to reason aboutchanges in the activities that constitute a work pro-cess. The more meta-data is available in standardized

Ž .form such as XML descriptions for incorporationinto inter-organizational information systems, themore sophisticated and efficient are the automatedrelationships that are practically realizable. From aninformation-theoretic perspective, meta-data and thesophisticated B2B relationships, it enables lower un-certainty in those relationships and thus permit avariety of cost-saving efficiencies.

Our research has shown that one type of informa-tion about processes, the goals of the process and its

activities, when properly structured, allow inferencesto be made about changed processes. Goal informa-tion permits these inferences because goals are far

w xmore stable than activities 9 . Our technique essen-tially attaches coordinating triggers to goals, whichat some level remain constant even as activities toachieve the goal are dynamically changing. That is,the set of subgoals, functions, and activities originat-ing from a goal are always recognizable as Athesame asB in some important sense, any other set ofsubgoals, functions and activities that also satisfy

w xthat goal 2 . It is precisely the ability of an inten-tional structure to change its instantiation while re-taining the explanatory power of the higher-levelnodes that gives our technique its utility.

A Hierarchical OÕerlay of Process IntentionŽ .model HOPI is a tree structure of goals and sub-Ž .goals intentions terminated by the activities that

actualize the goals which are attached to generalizedfunctions, as shown in Fig. 7. The general applicabil-ity of HOPI derives from its basis in the widelyaccepted decomposition model of problem solving

w xactivity 18 . With reference to Fig. 7, all processesbegin as a high level intention to accomplish a

Ž .complex multi-activity action. This intention iscalled the root goal in HOPI. The root goal ishierarchically decomposed during the design processinto progressively less abstract sub-goals. The de-composition takes place recursively in a problemdomain or problem space. At some point in a suc-cessful decomposition, the goals are sufficiently con-

Fig. 7. A hierarchical structure of intentions as an overlay of process representations.


crete that techniques for accomplishing the sub-goalscan be assigned to them.

Ž .The path from the root goal R to any activity ina work representation is termed the intentional con-text of the activity since tracing a path from activityto root goal explains the activity at progressivelyhigher levels of abstraction. For example when weask why the activity is performed, we explain that itis necessary to implement the generalized function towhich it is attached. The reason for the enactment ofthe generalized function is the operationalizationŽ .satisfaction of the sub-goal to which it is attached,and so on.

HOPI does not provide a process description orrepresentation. Rather, HOPI captures additional in-formation that can be used in conjunction with aprocess representation for reasoning about processes,and especially for drawing inferences about processchanges. As such, it is general and applicable to anyrepresentation. Naturally HOPI and the coordinationmodel based on it depend on the availability ofintentional information. Today a strong case can bemade from a review of the knowledge managementliterature that such information is being sought andcaptured for its considerable value even when it is

w xnot structured into a formalism such as HOPI 4 . Atleast one other workflow architecture has incorpo-rated goal information into its process descriptionsw x13 . This system uses goals for dynamic re-planningof a workflow within a single organizational entityrather than for coordination of multiple workflows,

but the increased functionality of that system sup-ports the high utility of goal information about pro-cess.

Several other mechanisms are under research aspotential solutions to the interoperability problems atthe process definition level. These typically involvegraph theoretic methods with formal logic, e.g. Petrinets, to infer the similarity of changed to original

w xprocess models 15,20 . While each technique has itsmerits, we believe the hierarchical nature of HOPI ismore flexible in the sense that more radically alteredprocess descriptions can be recognized as AsimilarBusing this scheme.

4.2. How it works

In a WfMS using HOPI, each workflow, de-scribed in virtually any format, is linked to its goalstructure. The triggers that indicate the states ofprocess that should be monitored are linked to spe-cific activities and portions of the goal structure that

Ž .indicate the meaning of the state see Fig. 8 . In anyprocess model, the process state must also be linkedto a specific activity, since it is only by receivingconfirmation that a concrete activity has been startedor finished that the state can be observed. Within theHOPI conceptualization the completion of a set ofactivities linked to a goal is said to satisfy the goaland goal satisfaction takes the process to a new state.If a new altered process is substituted for the original

Ž .Fig. 8. Intentional specification of activity monitoring cf. Fig. 2 .


process, providing the new process has a HOPI also,an intelligent subsystem can compare the two pro-cess descriptions and determine the new concreteactivity to monitor to indicate achievement of a highlevel state.

w xThe HOPI inferencing algorithm 10 works byfinding the best match in the new process goal treeto the path from the root goal to the original triggeractivity in the original process. Fig. 8 shows thealgorithm graphically as it relates to the order fulfill-ment scenario of Fig. 2. In both figures and thescenario, the activity that indicates the state of Com-pletion of Schedule Shipping is the activity de-scended from that goal. Irrespective of how thatactivity changes, or even how many activities arerequired to satisfy the goal under different processimplementations, an appropriate concrete activity tomonitor to alert cooperating workflows of theachievement of state can always be located.

The Original Process of Fig. 8 corresponds to theManufacturer’s workflow as both Manufacturer and

Ž .Retailer understood it at one time say, t in their0Ž .relationship. However, at some future time t the1

Ž .Manufacturer changes vendors Shippers and re-in-stantiates the actual activities of the workflow asshown in the Changed Process segment of Fig. 8.Without the HOPI interpreter, coordination betweenthe Manufacturer and all business partners who de-pend on the specific activity Schedule UPS Pickup– –to trigger activities in their workflows is disrupteduntil all parties have been formally notified and theirWfMS reprogrammed. This is a high cost modifica-tion. With HOPI, the change is detected, corrections

made automatically, and human supervisory person-Ž .nel notified of the change. Human high cost inter-

vention required for process changes is, in manycases, limited to quickly assessing, and then accept-ing the modification suggested by the system.

5. Enabling more complex business relationshipswith monitored–nested workflows

From the ability to correct for minor coordinationdisruptions arising from dynamic process changeŽ .via HOPI emerges the potential for more sophisti-cated e-business relationships than are now possible.Consider again the base order fulfillment scenariodepicted in Fig. 2. Even greater time efficienciesthan those that result from the optimization shown inFig. 2 are possible if the Retailer serves as a coordi-nating contractor for both the Manufacturer and theShipper. This changes the relationship between ser-vice providers entirely, as one WfMS is now thecoordination nexus for multiple services. This typeof coordinating relationship is frequently termed acontractor–subcontractor relationship and appearsas the basic interaction model for business areas asold as the construction industry and as new as virtualcorporations. The order fulfillment scenario reorga-nized under a contractor–subcontractor model isshown in Fig. 9.

Three of the many business reasons for adoptingthis arrangement are quality control, leverage withsuppliers and single-source service delivery to the

Fig. 9. Order fulfillment via a contractor–subcontractor relationship.


customer. We propose this as the second scenario inour suite of benchmark WfMS scenarios.

Ž .The Retailer center column is now the instigat-ing force—the primary contractor—in control of theinitiation of the sub-processes in Shipper and Manu-facturer. With the ability to monitor the workflowsof its subcontractors and preserve their autonomyŽthat is, monitor while not limiting their ability to

.modify their internal processes the Retailer canorchestrate the entire multi-entity process. Schedul-ing of shipping has been taken over in this scenarioby the Retailer who monitors the Manufacturer’sprocess to observe Schedule Production before acti-vating its Schedule Shipping activity. Retailer thenmonitors the Shipper’s workflow to determine whenthe activity Schedule Van has been completed. Thisinitiates the InÕoice Customer task in its own work-flow. In proposing this scenario as an optimization,we make certain assumptions that may not be true inall business environments. However, the value ofHOPI is its ability to allow any desirable inter-organizational workflow to be put in place and thenmaintained at a relatively low cost under conditionsof gradual autonomous process evolution.

5.1. LeÕeraging today’s online trading communitieswith HOPI

We discussed at the beginning of this paper howthe recent development of online trading communi-ties has been responsible for much of the increase ine-commerce. These same Internet sites can be easilyleveraged to more sophisticated trading relationshipsusing the techniques we have described as well asother meta-data enabled methods. The key technol-ogy underlying this capability is the nearly universal

Žuse of the meta-description language XML eXtensi-.ble Markup Language in these new trading commu-

w xnities 6 .XML-izing HOPI is a simple matter of specifying

Ža tree or more generally a directed-acyclic graph—.see Fig. 7 in XML. Fig. 10 shows a complete XML

Ž .document type definition DTD for HOPI, as it isimplemented in our prototype. We believe the funda-mental structure of HOPI and thus of the DTD isunlikely to change. However, as additional richnessis added to the model, we can foresee attributes

Fig. 10. XML document type definition for HOPI.

being added to each element specifying XML-LINKs—hypertext references—to lower level XML docu-ments which give structure to each of the currentlyatomic nodes.

A HOPI tree formally terminates in leaf nodesthat represent activities. However, in what is termeda generic HOPI, branches may terminate at functionor even subgoal nodes. The level to which the HOPIis defined reflects the level of constraint on theenactment of the root goal. An infinite number ofgeneric HOPIs can be specified for each root goalreflecting the degree of delegation of the process thatis acceptable—the greater the specification, the lessdelegation. A generic HOPI in turn may be ex-pressed by an infinite number of activity sets that

Žimplement its goal set the intentional process speci-.fication . The implementing activity sets are called

instantiations of the HOPI, and in practical use ageneric HOPI is linked to an instantiation expressedin any process description language.

Ž .XML product, form i.e. invoice, receipt , andprocess definitions already exist on multiple freely

w xaccessible trading sites 16 . In fact, the nature ofthese electronic marketplaces is to encourage publicregistration of and access to these descriptions. Thisis the mechanism by which accurate machine com-parison of price and product data proceeds. Althoughthe HOPI XML document type definition that allowsit to function as a process description overlay isprocess definition dependent, only minor changes arerequired in the HOPI template to link lowest levelgoals to the activity descriptions of any XML pro-cess description. This type of maintenance is veryeconomical given the benefits that result. XML


parsers capable of turning any well-formed HOPIXML specification into the data structure to be uti-lized by our inferencing algorithms are widely avail-

Ž .able as subroutines or dll’s or subprograms forvirtually any programming environment. The infer-encing algorithm itself, though outside the scope of

w xthis paper, is also easily implemented 10 .Once generic HOPI overlays have been published

for a process, organizations can use their WfMS toenact optimized MNM transactions with suppliersand customers. In another paper we have describedhow HOPI goal trees are easily translated to XMLmessages within the Wf-XML standard protocolŽhttp:rrstunt.cis.gsu.edurprocess coordinationr–

.xml hopi.pdf . Wf-XML itself contains the message–primitives necessary for one compliant workflowenactment engine to start and monitor processes inanother engine.

Given that the WfMS which will interoperate areall Wf-XML aware, then a simple and efficientHOPI implementation would be as a wrapper layersurrounding the existing commercial workflow en-actment engine. The subsystemrlayer would operateat the level of Wf-XML messages and at that highlevel of operation, the impact on efficiency would beacceptable except in the most demanding applica-tions. The HOPI layer would examine all incomingWf-XML messages for HOPI content, and performtranslations if required, much as Message Oriented

Ž .Middleware MOM is used to provide data andmessage translation between heterogeneous legacysystems. Messages involving non-HOPI aware pro-

cesses or workflow systems, or messages that did notinvolve HOPI computation would be passed throughto the enactment engine unchanged. HOPI specificmessages would be translated to the appropriateŽ .series of AstandardB Wf-XML messages and then

Ž .passed through to or from the enactment engine.Fig. 11 illustrates this process.

With reference to Figs. 8 and 9, our techniqueresolves the changed activity situation presented inSection 4 and illustrated in Fig. 8 as follows:

v Retailer, working from a published XML de-scription of Manufacturer’s workflow, augmentedwith a HOPI overlay, determines it can optimize itsprocess by monitoring when Manufacturer schedulesshipping.

v Retailer issues a Wf-XML request to Manufac-Ž .turer to monitor advise when it has started the

activity Schedule–UPS–Pickup. Part of this requestreferences the work definition Retailer believes is inoperation at Manufacturer.

v Manufacturer’s HOPI subsystem intercepts theactivity-monitoring request. It compares the workdefinition transmitted from Retailer with Manufac-turer’s current workflow definition in which the

Ž .shipping activity has changed see Fig. 8 . The sub-system translates Retailer’s request so that the moni-tored activity is the new, equivalent activity—thefirst activity descended from the Schedule Shipping–subgoal.

v The subsystem then advises administrative per-sonnel at both sites of the change it has detected andthe suggested correction.

Fig. 11. HOPI processing implemented as a middleware service layer.


Though simple, this example illustrates both theflexibility that derives from the MNM model, andthe robustness that HOPI structured intentional infor-mation adds to the technique.

6. Conclusion and implications for practice

Many of the problems and the potentialities ofe-commerce are identical to those that have beenunder study for some time in the field of automatedworkflow management systems. As e-commerceevolves, the relationships between agents supportedby the underlying technology must also evolve. Inthe workflow community, the study of relationshipsbetween autonomous workflows and the technologyto model and enact them is termed interoperabilitymodeling. We have shown that common interoper-ability models are not sufficient to realize morecomplex commercial relationships, which involvemultiple parties and provide for considerable excep-tion handling. The monitored–nested model of work-flow interoperability we developed enables consider-able flexibility and is sufficient for our proposedbenchmark scenarios. Goal data about the processes,when structured in a hierarchy that reflects the de-sign of the process, can be interpreted by a workflowsubsystem to overcome some of the practical prob-lems that attend sophisticated interoperability mod-els.

The advent of multiple interoperable XML-basedrepositories on the Internet greatly extends the possi-bilities for augmenting basic inter-organizationalworkflow architectures with meta-data. Once re-search such as ours has established the type ofinformation required to enable a rich business rela-tionship, an XML description of that data can beposted to a globally accessible repository and down-loaded by any trading partner. In many instances,similar to our technique for enabling contractor–sub-contractor relationships with an overlay to conven-tional process descriptions, the additions to currentsystems can be made incrementally. A HOPI awaresubsystem can be implemented as a middleware shellaround any commercial WfMS which supports theWf-XML standard. In the same way, new e-com-merce potentialities can be explored and evaluated,

and the support technology debugged without largeinvestments or disruption to existing processes.

Acknowledgements

This work is partially supported by NSF ResearchGrants, IIS-9810901 and IIS-9811248, and a re-search grant to the second author from the RobinsonCollege of Business, Georgia State University.

References

w x1 Ariba Corporation, Ariba Commerce Center Architecture,commercial white-paper, http:rrwww.Ariba.comrcorprAribaSolutionsrariba commerce center architecture.asp– – –Ž .2000 .

w x2 L. Barsalou, Ad hoc categories, Memory and Cognition 11Ž .1983 211–217.

w x3 CommerceOne Corporation, Direct Materials E-Commercevia Multi-Enterprise Trading Exchanges, marketing whitepa-

Ž .per: http:rrwww.commerceone.comr 2000 .w x4 R. Dove, Knowledge management, response ability and the

Ž .agile enterprise, Journal of Knowledge Management 3 1Ž .1999 54–61.

w x5 J.R. Galbraith, Organization Design, Addison-Wesley, Read-ing, MA, 1977.

w x6 R. Glushko, J. Tenenbaum, B. Meltzer, An XML frameworkfor agent-based e-commerce, Communications of the ACM

Ž . Ž .42 3 1999 106–114.w x7 i2 Corporation, Marketplace Services: Vision,marketing

white paper: http:rrwww.i2.comrmarketplacesrvision.htmŽ .2000 .

w x8 A.K. Jain, M. Aparicio, M. Singh, Agents for process coher-ence in virtual enterprises, Communications of the ACM 42Ž . Ž .3 1999 62–69, March.

w x9 W.L. Johnson, M.S. Feather, D.R. Harris, Representation andpresentation of requirements knowledge, IEEE Transactions

Ž . Ž .on Software Engineering 18 10 1992 853–869.w x10 W. Kuechler, V. Vaishnavi, A goal-based model of coordina-

Ž .tion in interoperating workflows, in: March, Bubenko Eds. ,Proceedings of WITS ’98, 1998, pp. 85–94.

w x11 Y. Lei, M. Singh, A comparison of workflow metamodels,Ž .in: S.W. Liddle Ed. , Proceedings of the ER’97 Workshop

on Behavioral Models and Design Transformations: Issuesand Opportunities in Conceptual Modeling, 1997, http:rrosm7.cs.byu.edurER97rworkshop4rls.html.

w x12 T. Lewis, Service: the next inflection point, IEEE ComputerŽ .2000 126–128, January.

w x13 D.E. Mahling, R.C. King, A goal-based workflow system formultiagent task coordination, Journal of Organizational Com-

Ž . Ž .puting and Electronic Commerce 9 1 1999 57–82.


w x14 C. Petrie, S. Sarin, Beyond documents: sharing work, IEEEŽ . Ž .Concurrency 7 3 2000 34–36, May–June.

w x15 M. Reichert, P. Dadam, A framework for dynamic changesin workflow management systems, Proceedings of the 8thInternational Workshop on Database and Expert SystemsApplications, 1997, pp. 42–48.

w x16 RosettaNet URL: http:rrwww.rosettanet.org.w x17 A. Sheth, W. van der Alst, I. Arpinar, Processes driving the

Ž . Ž .networked economy, IEEE Concurrency 7 3 1999 18–31,July–September.

w x18 H.A. Simon, The New Science of Management Decision,Revised Edition, Prentice Hall, New York, 1977.

w x19 S.L. Star, The structure of ill-structured solutions: boundary

objects and heterogenous distributed problem solving, in: L.Ž .Gasser, M.H. Huns Eds. , Distributed Artificial Intelligence,

Morgan Kaufmann, San Mateo, 1989.w x20 W. van der Alst, Generic workflow models: how to handle

dynamic change and capture management information, Pro-ceedings of the 4th IECIS International Conference on Coop-erative Information Systems, 1998, pp. 1–13.

w x21 Workflow Management Coalition, Workflow ManagementCoalition Workflow Standard—Interoperability Abstract

Ž .Specification, Document Number WFMC-TC-1012 1996www.wfmc.org.

w x22 Workflow Management Coalition, Workflow InteroperabilityŽ .—Enabling E-Commerce April 1999 www.wfmc.org.

supporting optimization of business-to-business e-commerce ... · supporting optimization of...

Documents