A Paradigm for Decentralized Process Modelingand its Realization in theOz EnvironmentIsrael Z. Ben-SllaulGail E. KaiserDepartment of Computer ScienceColumbia UniversityNew York, NY 10027AbstractWe present a model for decentralized Process Cen-tered Environments (PCES), which support concertedeflorts among geographical ly-dwpersed teams — eachlocal team wtth tts own autonomous process — and em-pha.svze flezzbility in the tradeofl between collaborat~onvs. autonomy. We constder both decentralized processmodeling and decentralized process enaction. We de-scrtbe a reakatton tn the OZ decentralized PCE, whichemploys a rule-based forma ltsm, and also investigatethe apphcatton to PCES based on Petri- nels.1 Introduction and MotivationA process is a partially ordered set of steps for de-veloping a software system. In addition to definingthe steps and their interfaces to tools in some formalnotation, a process model also specifies prerequisites toeach step, the consequences of each step, and any syn-chronization among concurrent steps. Processes are“situated”,in the sense that different processes aresuitable for different personnel roles, lifecycle phases,projects, organizations, etc.Process Centered Environments (PCES) emerged inan attempt to provide flexible and extensible envi-ronments for developing software, by means of “pro-cess modeling”and “process enaction”. PCES (1)provide a formalism for defining project-specific soft-ware processes (modeling) and (2) take advantage ofwell-understood programming language implementa-tion techniques to “execute” the software process (en-action). Process enaction assists in performing thesoftware process as defined in the process modelinglanguage (PM L). Enaction can involve monitoring,guidance, automation, enforcement, constraining andcontrolling the workflow, and simulating parts or all ofthe software process. A specific instance of a P(3E isconstructed by tailoring a generic kernel that behavesas the enaction engine for the PML; this is typicallycarried out by a distinguished environment udnltnw-trat or, and is of no concern to the average environmentuser who participates in the process.Why Decentralization?Large-scale product development typically requiresparticipation of multiple people, often divided intomultiple groups, each concerned with a different facetof the product. For example, one software productmay require teams for requirements elucidation, func-tional specification, design, coding, testing, document-ation, and maintenance; another product may involvemultiple teams, in this case with each responsible forfull development of a distinct component of the sys-tem, Each team uses its own selection of tools, andpossibly its own private data and management poli-cies. At the same time, the teams need to cooperatein order to develop the product, and as studies in soft-ware engineering have shown, the interaction amongteam members accounts for a significant fraction ofthe total cost of the product being developed [12].The degrees of autonomy and collaboration both de-pend on the nature of the product being developed andon organizational policies. Sometimes multiple organi-zations collaborate on a product, in which case auton-omy (privacy or security) is a “hard” constraint thatcannot be compromised. With the advent of high-speed networks and enhanced communication facili-ties, geographical dispersion and time shifting is anadditional possibility, particularly among teams (asopposed to within a team).This paper explores modehng and enactzon of inter-group collaboration among independent, autonomousand, possibly, pre-exastzng processes. This is in con-0%?70.5257/94 $3.()() @ 1994 IEEE179trast to work on (1) supporting intra-group collab-oration and synchronization, where multiple team-members (cooperate within the same process, possi-bly with different “views” [7, 3]; and (2) process mod-ularization, where a single process is decomposed intosub-processes both for modeling and enaction pur-poses [21]. We further distinguish between distribu-tion and decentralization. A distributed system is onethat provides a single logical perspective, but is phys-ically distributed into multiple computing units, usu-ally across machines of a single site. (We use the term“site” to mean an administratively cohesive Internetdomain sharing a network file system.) That is, adistributed system transparently shields the distribu-tion from its applications. In contrast, a decentralizedsystem is comprised of relatively independent subsys-tems with some degree of correlation between them,often (although not necessarily) spread among multi-ple sites. Here, transparency is intentionally not sup-ported because it violates autonomy and because therange of access costs must be distinguished.Environment distribution is a form of “vertical”scale-up, in that it allows for more users to work,but under the same process and within some boundedphysical distance (typically a local-area network).This paper explores “horizontal” scale-up, where thenumber of users per group sharing the same processmay not grow much, but the number of groups may bearbitrarily large, each group with its own private pro-cess and data but collaborating in a concerted effortwith the other groups.An “international alliance” metaphor for our modelof Decentralized PCES (henceforth DEPCES) is usedthroughout the paper, where the default is for inde-pendent countries to operate autonomously and co-operate only in accordance with treaties (in analogyto NATO). This is in contrast to the “corporation”model of decentralization suggested by Shy et al. [23],whereby subunits of a corporation do not have anyexistence independent of the corporation.2 RequirementsThe following is a list of the main requirementsthat a DEPCE should fulfill (for centralized multi-userPCE requirements, see [7]):1. Process Autonomy — Each local sub environment(henceforth SubEnv) should control autonomously itsprocess and its data, while allowing access to themby remote SubEnvs under restrictions that are solelydetermined by the local SubEnv.A related requirement is that a SubEnv should beself-contained and operationally mdependeni. That is,it should be able to behave as a complete environ-ment by itself when not collaborating with any otherSubEnvs, and SubEnvs must be able to operate con-currently and independently, except when their pro-cesses explicitly collaborate.2. Process Collaboration