Process Enactment in Virtual Software Organizations

Process Enactment in Virtual Software Organizations

John Noll

Computer Engineering Department

Santa Clara University

500El Camino Real

Santa Clara,CA95053-0566

Abstract

The conventional approach to process enactment employs a client-server architecture,in which a cen-tral engine executes process descriptions and often stores documents produced by the processes.This ap-proach has been successful for automating processes in many situations.However,it relies on a signi?cant centralized computing infrastructure,which does not ?t distributed,loosely coupled“virtual organizations”such as open source software projects.

This paper presents a process enactment solution for such virtual organizations,based on three im-portant features:A completely distributed,peer-to-peer architecture that eliminates the need for cen-tralized computing and organizational infrastructure; process modeling based on independent process frag-ments that can be performed by a single individual ac-tor;and,coordination entirely through products pro-duced and consumed by concurrent processes.

Keywords:work?ow,peer-to-peer,virtual organiza-tion,process enactment

1.Overview

The conventional approach to process enact-ment employs a client-server architecture,in which a central engine executes process descriptions and often stores documents produced by the pro-cesses[1].Process participants(actors)interact with the engine through web browsers,whole en-vironments,or task-speci?c tools,receiving guid-ance on what activities to perform,and how to perform them.This approach has been successful for automating processes in many situations,espe-cially business processes in large enterprises.

In part,this is due to the engine’s global visibil-ity of the organization:because all processes are enacted in a central location,concurrent processes can be closely coordinated,and work can be ef?-ciently allocated to members of the organization.

However,this effectiveness comes with a cost: it requires signi?cant central computing infrastruc-ture,central administration,and a large support or-ganization.These costs are readily borne by“en-terprise class”organizations,but are prohibitive for other kinds of organizations that lack the physical and organizational structure required.

For example,open source software development can involve large numbers of people,yet the re-sources and infrastructure of the project are com-pletely distributed among the participants.There is no building or IT organization to support a large computing facility.

This is an example of a“virtual organization”: a dynamic,loosely coupled,widely distributed group of actors who cooperate to achieve some common goal.Virtual organizations share the fol-lowing characteristics:

Complete distribution-members of the group are dispersed throughout the world,com-municating primarily via email,the World Wide Web,Network News groups,and sim-ilar Internet-based mechanisms.

Fluid membership-members join and leave the group at will.

Organic structure-there is little hierarchy, and participants assume roles as needed, based on their perceived contribution toward the group’s goals.

CODE

RESULTS

CODE

Setup

Tear down Run tests (tester)

(tester)

Unit Test Debug Commit

(programmer)

(programmer)

(programmer)

(programmer)

DESIGN

Implement

(tester)

Figure 1.Coordinated Process Fragments

Minimal infrastructure -a member’s em-ployer may donate disk space for archiving the group’s documents,but there is no build-ing or support organization,and little if any budget or paid staff.

Thus,while they could bene?t from process support,these virtual organizations lack the struc-ture and resources to deploy traditional enterprise-oriented client-server based process enactment.In this paper,I propose a process enactment so-lution for virtual organizations,based on three im-portant features:A completely distributed,peer-to-peer architecture that eliminates the need for cen-tralized computing and organizational infrastruc-ture;process modeling based on independent pro-cess fragments that can be performed by a single individual actor;and,coordination entirely through products produced and consumed by concurrent processes.

2

Approach

2.1

Modeling

Because the participants in a virtual organiza-tion are autonomous,distributed,and continually changing,processes have to be modeled differently than they would in a conventional enterprise ap-proach.The process model must account for the fact that the process performers (actors)are in-dependent,autonomous agents.This means they make decisions individually about what processes and tasks to perform,and when.

To accommodate this reality,my approach de-composes organizational processes into concur-

rent,independent process fragments,that cooper-ate to achieve a common goal.Each fragment con-sists of an ordered set of tasks (called actions )per-formed by a single actor;this feature means that a given actor can instantiate and perform a process fragment without affecting other actors,thus pre-serving each actor’s individual autonomy.

These processes are synchronized through the work products they share (see below),so that even though each actor works autonomously,their ef-forts contribute to the common organizational goal.

2.2Coordination

In order to preserve the highest possible de-gree of autonomy and independence for actors,coordination between processes is modeled as re-source sharing.Activities can block until a re-source (product,document,or other artifact)is pro-duced by another activity performed by a different actor.A predicate in the process description spec-i?es the state that required resources must satisfy before the activity can proceed (the mechanism is described fully in [2]).

An example of a simple software implementa-tion and test process is shown in Figure 1.This process is decomposed into two fragments:one bound to the programmer,comprising implementa-tion tasks,and one bound to the tester,comprising system testing tasks.The two fragments are syn-chronized through the shared “CODE”resource;as a result,the testing fragment doesn’t begin until the programmer completes the Commit task,thus making the “CODE”resource available for testing.Note that because the processes are indirectly coupled,it is not necessary for all activity to be

modeled,or enacted;enacted work?ows can be co-ordinated with ad-hoc work or activities in another organization,through a shared resource.Thus,the implementation fragment can begin as soon as the “DESIGN”resource is available;but this resource can be produced by any process(or no formal pro-cess whatsoever).

2.3Enactment

The enactment mechanism is based on a peer-to-peer architecture.Each actor runs an instance of the enactment system;these instances are entirely independent.It is assumed that the resources pro-vided and required by actors’processes are avail-able from a shared distributed repository,such as the World Wide Web.

An example,showing enactment of the implementation-test process discussed above,is shown in Figure2.In this example,one program-mer and three testers coordinate to implement and test a body of code.They share resources through a global code repository(hosted by an entity such as SourceForge).

The arcs labeled“notify(code)”signify noti?-cation of a change in the code resource,an event detected by each of the participating testers’enact-ment system.

3Related Work

Several research efforts have addressed different aspects of the problem of providing process sup-port for distributed,autonomous organizations.

For example,Exotica/FMDC[3]was system de-veloped by IBM to support mobile and discon-nected clients.Exotica/FMDC is an extension of the Exotica[4]work?ow system,and is thus es-sentially a client-server architecture with features to allow the clients to operate when disconnected from the server.

Milos[5]speci?cally addresses process support for distributed software development teams.It is also a client-server architecture,but clients may be widely distributed across the Internet.The authors propose future extensions to the Milos architecture to allow Milos servers to coordinate with other Mi-los servers on a peer-to-peer basis.Thus,Milos may evolve into a hybrid client-server/peer-to-peer architecture,in which work groups would share a server,and virtual organizations would consists of such workgroups assembled in a peer-to-peer fash-ion.

Magi[6]also follows a peer-to-peer architec-ture.Magi is a framework for constructing work-?ow applications,providing a set of protocols and services based on a scaled-down version of the popular Apache web server.Magi’s goal is to en-able construction of work?ow systems comprising mobile devices as well as traditional desktop com-puters.While Magi shares the goals of support for disconnected/mobile peers and wide distribu-tion,it assumes that peers executing components of a process trust each other,so that they can cre-ate and update,as well as read,documents on peer nodes.Also,Magi assumes documents as well as processes are managed by the Magi servers.Thus, Magi could be viewed as a framework for deploy-ing peer-to-peer work?ow in an enterprise context. 4Conclusion

The approach described herein has several dis-tinctive features.

First,since individual actors each have their own enactment system,they can bring work?ow sup-port to groups to which they belong,without im-posing on other group members.

Second,because the enactment system assumes that resources and products are stored in an exter-nal database,it works with,rather than replaces, existing data repositories.As a result,coordination can be achieved across organizational boundaries, and between work?ow peers and ad-hoc processes, as long as the shared resources are accessible to both.

Further,because the coupling between coordi-nating actors is indirect,through a shared resource, there is no requirement for trust(or even aware-ness)between coordinating work?ow peers.This enables extremely?uid,dynamic organizations in which participants can join at will without requir-ing administrative approval or action.

Finally,processes can be performed off-line, and synchronized periodically when desired or possible.This is especially important for mobile

Figure2.Peer-to-peer Enactment Architecture

actors,who often work with intermittent network connections.

References

[1]David Hollingsworth.The work?ow reference

model.Technical Report TC00-1003,Work-?ow Managment Coalition,January1995. [2]Bryce Billinger.Modeling coordination as re-

source?ow–an object-based approach.Mas-ter’s thesis,University of Colorado at Denver, September2000.

[3]Gustavo Alonso,Roger Gunthor,Mohan Ka-

math,Divyakant Agrawal,Amr El Abbadi, and C.Mohan.Exotica/FMDC:A work-?ow management system for mobile and dis-connected clients.Distributed and Par-allel Databases,An International Journal, 4(3):229–247,1996.

[4]C.Mohan,Gustavo Alonso,Roger Gunthor,

and Mohan Kamath.Exotica:A research per-spective on work?ow management systems.

IEEE Data Engineering Bulletin,18(1):19–26, March1995.

[5]Frank Maurer,Barbara Dellen,Fawsy Ben-

deck,Sigrid Goldmann,Harald Holz,Boris

Kotting,and Martin Schaaf.Merging project planning and web-enabled dynamic work-?ow technologies.IEEE Internet Computing, May/June,2000.

[6]Gregory Allen Bolcer.Magi:An architecture

for mobile and disconnected work?ow.IEEE Internet Computing,May/June,2000.