Management of collaborative processes involving multiple parties is one of the dominant topics in contemporary information system research. While the process perspective is quite well understood and supported by a wide range of modeling approaches, it is necessary to go beyond the process perspective alone. We specifically address the following question: If we consider the involved parties of a collaborative process as a team, then (1) which are the general formation rules for such a team together with the collaborative process it carries out and (2) to which concrete underlying organizational structure do these rules apply? To address this question, we present the organizational modeling approach Sonar. The accompanying models are rather high-level and illustrative but at the same time they are rich enough in order to generate executable models and other kinds of code that together form the core of a middleware implementation for team-oriented process management.
Management of collaborative processes involving multiple parties is one of the
most dominant topics in contemporary information system research, especially
in the field of business process management (BPM) but also on a smaller scale in
the field of computer-supported cooperative work (CSCW) or community
support. The process perspective itself is quite well understood and there exists
a wide range of more or less similar process modeling approaches (differing in
specific aspects), including workflow nets and their descendants [
To answer this question, a more comprehensive modeling approach is
necessary, encompassing both a system’s processes and structure in an integrated
manner. While this is to some extent addressed in the field of enterprise
architecture management (EAM), EAM is a rather high-level discipline and is at least
not necessarily concerned with models whose primary purpose is to be directly
transferred into software artifacts (although this may be true for some parts,
especially for process models). Contrary to that, the field of organization-oriented
multi-agent systems is primarily concerned with rather comprehensive
organizational models that exhibit a close gap to software-technical deployment [
In this context of process and overall organizational modeling, we present the Petri net-based organizational modeling approach Sonar (Self-Organizing Net ARchitecture).1 It explicitly addresses the question from above concerning structure and process perspectives in teamwork modeling. We provide a way to capture the whole context of team-oriented process management: from the underlying organizational structure over team formation up to process execution by the team.
We have laid specific emphasis on achieving the following combination: (1) Sonar models are simple enough to be easily understood and analyzed (by means of standard Petri net tools). (2) Sonar models are rich enough to capture the interplay of various organizational concepts in such detail that we can automatically generate executable models and other kinds of code from them. In this context, Figure 1 gives an overview of the results we present in this paper. We concentrate on the modeling approach and in which ways model parts are 1 We are not dealing with the “self-organizing” part in this paper, but see the conclusion. made executable or other code is generated from them. The figure can be regarded as capturing the most fundamental way of applying our Sonar approach. In the outlook of the paper we address several extensions that build upon it, but here we just regard the basic case. A manager creates a high-level organizational model that is void of execution details. The different model parts undergo a preliminary deployment phase where they are pre-processed and then passed on to a middleware layer for team-oriented processes management. Here, models are actually deployed and support the different phases/aspects of teamwork. Some of the pre-processed model parts are persistent and directly used while others serve an on-demand generation of temporary executables. Users access the middleware layer and act as organizational members that participate in teamwork (this users might be social but also artificial/software-technical actors).
In the remainder of the paper, we flesh out this rather abstract description. In Section 2, we introduce the Sonar modeling approach. In Section 3 we elaborate on transformations of original Sonar models in order to obtain code from them and in Section 4 we describe how this code is embedded in an agent-based middleware for teamwork. We conclude our work in Section 5 and give an outlook to advanced and future topics of our research.
Note that both the Sonar modeling approach and the middleware
implementation rest on our previous work (cf. especially [
For organized activities two fundamental (and opposing) requirements have to be taken into account, the division of labour into various tasks and the coordination of carrying out these tasks. For Sonar, this can be rephrased more concretely and with reference to the terminology used in the introduction of the paper. Coordinated carrying out of tasks corresponds to a team executing a distributed (multi-party) workflow (DWF). Division of labor corresponds to the formation of such a team together with a DWF definition. Formation takes place according to general formation rules and a specific organizational structure to which these rules are applied. Consequently, Sonar models center around the duality of DWF (process) and organizational structure models. Both sides have to be coherently related with one another.
Sonar is based on Petri nets which offer both a graphical representation and
formal semantics. In [
We will consider a running example throughout the paper. As Sonar models are based around the duality of distributed workflow (DWF) and organizational structure models, we could start with either of them. Here we begin with the workflow perspective. Figure 2 shows a DWF for collaboratively submitting a paper. The DWF is distributed in the sense that it encompasses multiple roles, here providePaperFrame and providePaperBody. Each action of the DWF is mapped onto exactly one role. Actions are modeled as transitions. They are connected by places. Places connecting actions belonging to the same role form the DWF life line of that role and we arrange such a life line vertically in our models.2 Places connecting actions of different roles can best be considered as message transfers between roles and we draw them as horizontal connections. One can consider the places between the transitions of different roles as the interface between these roles. Places and transitions of a DWF model are named. Names of message places are prefixed with a key for the role sending that message (for example ppf: for the role providePaperFrame). Such message place names have to be unique across the whole set of DWF models of an overall Sonar model (see below for the reason). If a DWF model is decomposed into role parts and there exists an interface between two roles, each role part gets its own copy of the corresponding interface places.
Figure 3 shows another DWF. More exactly, it shows a DWF fragment. This fragment consists of two roles supervisePaperSubmission and writeIntroAndConclusion. These two roles can be used to refine the role providePaperFrame from 2 Of course, we do not rely on graphical arrangements in order to determine the different role parts of a DWF. We are currently working on an action inscription language for DWF transitions. So far, such an inscription does at least contain the name of the role that the transition belongs to. This is even more important when DWF life lines are not just sequences as in the rather simple examples in this paper. They may include forks, joins and concurrency. However, we have omitted the transition inscriptions in the DWF figures of this paper as the different role parts should be easily identified. behavior of the substituted roles and the overall composition thus fits together. To conclude, we arrive at basically four possible DWFs for jointly submitting a paper. Further models of role refinements would lead to more possibilities of DWF composition. It remains to supplement such a set of DWFs and DWF fragments with a model that determines not only when to compose which DWF parts but also who takes on which roles in a finally composed DWF. This is where Sonar organizational structure models come into play.
Organizational structures in Sonar are basically modeled as delegation
structures. Figure 5 shows such a delegation net for the running example of joint paper
submission.3 A Sonar delegation net comprises multiple positions that are
abstractions of actors (that occupy these positions when a Sonar organization
is deployed). Positions are modeled as grey boxes that partition an underlying
task structure. In Figure 5, we have as positions a supervisor, a phd student and
two students that distribute tasks among themselves in order to jointly submit a
paper. The underlying task structure is modeled as a Petri net. A place models
a task and a transition models the implementation of a task. For this purpose,
each transition has exactly one place in its preset. Task implementation can take
on multiple forms and transitions are named accordingly:
3 Delegation nets have been over-hauled compared to previous publications, cf. [
The explicit inscription of transitions with the implementation type that they represent leads to slightly larger but much more readable models. 1. Execute: The task is directly executed. 2. Delegate: The task is delegated. 3. Refine: Sub-tasks for a task are determined. 4. Split: A task is split into (already determined) sub-tasks.
The latter two cases are typically combined. All the implementation cases appear in Figure 5. Delegations are the kind of task implementation that relates two positions while refines, splits and executions are internal to positions.
The intertwining of a Sonar delegation net with DWF (fragment) models lays in the nature of the tasks. Each task in a delegation net corresponds to one or more roles in a DWF. Consequently, the places in Figure 5 are named according to the pattern DW Fa[role1, ..., rolen], meaning that the task corresponds to implementing the roles role1, ..., rolen from DWF DW Fa. Combining a delegation model with a set of DWF models leads to a straightforward notion of well-formedness of an overall Sonar model: (1) Delegation has to start with an initial task that corresponds to all roles of a complete DWF model (not a DWF fragment) and (2) task refinements must map onto associated role refinements in the set of DWF (fragment) models. Consequently, Figure 5 shows one possible delegation model for the DWF models from Figures 2 – 4 (likewise, other sets of DWF models may fit to the delegation model).
This way, the process perspective represented by DWF modeling is
supplemented with an organizational structure perspective that guides both the
formation of teams (where positions represent the team members) and the associated
team DWFs. For example, the delegation model from Figure 5 allows multiple
teams to be formed. An interesting fact is that team formation actually
corresponds to the possible firings of the delegation net, its Petri net processes, cf. [
Using Petri nets as the basis for Sonar modeling allows us to to take
advantage of well-known analysis techniques. As we rely on simple place/transition
(P/T) nets, there exist standard techniques and tools for checking the soundness
of workflow net models or the free-choice nature of delegation models (cf. [
The models presented so far have been on a relatively high level. They are basically P/T nets, where some naming conventions have to be followed. There 4 http://www.promtools.org/ are no execution details, except for the fact that Petri nets inherently have an operational semantics. It is not even necessary to model all possible DWFs that can occur during the execution of a Sonar organization. Instead, it is sufficient to model some initial DWF models and then just add models for selective role refinements.
In order to utilize the models in the context of a Sonar-based middleware layer for teamwork, some deployment steps are necessary. Based on the preceding section, it is now possible to be more specific on the model-driven support for teamwork illustrated in Figure 1 from the introduction. Figure 6 shows a Sonarbased re-interpretation of the figure.
After checking well-formedness of all aspects of an overall Sonar model (see
the previous section), the first phase of model deployment is pre-processing.
One immediate question is whether to use the Petri net models themselves
(enriched/extended for deployment)5 or whether to transfer them into other
artifacts. Although we do not deal with run-time re-organization in this paper,
this aspect has a strong impact on answering this question. Changing the Petri
net models and re-deploying them at run-time can get quite cumbersome and
costly. Currently, we have decided to use the DWF models directly in their Petri
net form and to transfer the delegation model into a Java data structure. We
treat DWF models and thus how things are basically done as rather fixed and
the role parts as the basic behavioral building blocks. Fundamentally
changing the DWF models is often better done by starting from scratch (however,
instead of changing DWF models, they can be extended by further role
refinements). The delegation model on the other hand and thus the context leading to
the actual behavior is prone to quite frequent and light-weight re-organization
efforts: adding/removing positions, adding/removing delegation relationships,
adding/removing execution etc. Consequently, we prefer a data structure that
handles changes easier. In addition, such a data structure is helpful to share
(communicate about) and process knowledge in the context of team formation
(determining eligibility of task implementations, possible delegation partners or
whole sub-teams etc.). To conclude, the pre-processing phase of model
deployment comprises two parts.
5 This is what we did for our previous versions of a Sonar middleware layer, cf. [
Basically, the Java data structure of the delegation model is used to manage task delegation and thus the team formation process. As soon as a team is formed, there is a unique team DWF associated with it: It is the composed DWF that consists of the role parts that are implemented by execute (instead of refine, split or delegate) transitions during the delegation process. The wellformedness of an overall Sonar model ensures that these role parts fit together. For example, the composed DWF from Figure 8 is the team DWF for a team where the delegation process has lead to the maximum level of task (and thus role) refinement for the running example of joint paper submission.
Consequently, team formation leads to an on-thy-fly generation of the corresponding team DWF. However, for such a team DWF to be executable in the context of the middleware layer, a further refinement and enrichment has to be carried out. This is also done by automatic generation. Basically, each action transition of a team DWF has to be enriched with execution inscriptions and has to be divided into a call and return part. Figure 9 exemplifies the substitution rule applied to a DWF transition for the addConclusion action of the team DWF from Figure 8. The transition is split into two transitions for call and return. The names of places lead to the generation of variable names that are bound to work-item and result objects of the action. The action call is parametrized with the role name, action name and a set of incoming work-items. The surrounding engine for the execution of team DWFs has to take care of forwarding the call to the position holder that implements this role for this team. In addition, the engine generates a unique action ID that can be used to associate action call and return. The action return is parametrized with a result object. We omit details on handling erroneous or aborted execution of DWF actions here.
Figure 10 shows the class diagram for content objects used in the context of executable team DWFs. More specifically, it shows the generic part. Concrete Sonar models are intended to extend the concept dwf-action-content with customized concepts. In fact, we are working on a high-level action inscription language for Sonar DWF models. Such a language can for example be used to attach pre-conditions, post-conditions and effects for/of DWF actions based on the content objects and their attributes that are involved in the action. For this purpose it is necessary to explicitly define the according custom concepts.
To conclude this section, the illustrative and rather high-level Petri net models that a modeler has to create for a Sonar organization are rich enough to allow the generation of different kinds of executable artifacts for computer-supported teamwork. In the next section, we give an overview of a middleware implementation that utilizes these artifacts. 4
We present a middleware implementation for teamwork support that is based on
Sonar models and their deployment. There exist of course multiple possibilities
and here we present our current approach, called Mulan4Sonar. This name
stems from the fact that it is based on the multi-agent system (MAS) framework
Mulan (cf. [
Figure 11 shows our general proposal for multi-agent system deployment of Sonar models. We have an organization agent that represents the Sonar organization as a whole. It is responsible for initialization and for keeping a global perspective. With each position of a Sonar model we associate one dedicated agent, called an organizational position agent (OPA). From a conceptual point of view, the resulting OPA network (together with the organization agent) embodies a formal organization as each OPA represents an organizational artifact and not a member/employee of the organization. From a technical point of view, the OPA network is an agent-based middleware layer for supporting teamwork according to Sonar models. Consequently, each OPA represents a connection point for an organizational member agent (OMA). Each OMA interacts with its associated OPA to carry out organizational tasks and to make decisions where required. An OPA both enables and constrains organizational behaviour of its OMA. The OMA can effect the organization only in a way that is in conformance with the OPA’s specification. In return, the OPA relieves its OMAs of a considerable amount of organizational overhead by automating coordination and administration. Conceptually speaking, OMAs implement/occupy the formal positions and thus represent the informal part of the organization. Note that an OMA can be an artificial as well as a human agent. OMAs might of course only be partially involved in an organization and have relationships to multiple other agents than their OPA or even to agents completely external to 9 An example for using Java inscriptions in the context of a Petri net model was already shown in Figure 9. The other way round is equally possible, namely having Java objects monitoring, triggering or even controlling parts of the execution (simulation) of a Petri net model. the organization. From the perspective of the organization, all other ties than the OPA-OPA and OPA-OMA links are considered as informal connections.
Our current implementation of Mulan4Sonar follows this general proposal.
However, it does not (yet) feature OPAs as distinct agents. Instead, our current
implementation features a central organization agent that manages the teamwork
processes of a Sonar organization but also utilizes separate OPA shells for each
position. Consequently, we have already prepared the implementation in way to
be able to single out the shells as OPAs and thus to obtain a more distributed
implementation. Figure 12 shows the three-level architecture of the organization
agent in its current form. This architecture is actually realized based on the
high-level Petri net concept of nets-within-nets [
On the top level of the organization agent, the organization is initialized and the pre-processing of the original Sonar models is carried out, just as described in the previous section. Afterwards, the teamwork engine is initialized with the pre-processed models as input and represents the second level.
The teamwork engine sets up OPA shells for all positions and makes the delegation model available to them. We will not go into detail concerning the manifold responsibilities of the OPA shells. We just assume that basically, they take care of binding users as members (OMAs) into the organization and manage the inclusion of the OMAs’ actions and decisions in conformance to the organizational specifications. New teamwork activities can be started and represent the third level. Teamwork activities and OPA shells stay connected via the teamwork engine level.
A teamwork activity basically comprises the delegation process for team (DWF) formation and afterwards the execution of the composed team DWF by the team members that take on roles in the DWF. All of this is managed by the teamwork activity level, together with the involved OPA shells that can be consulted via the joint teamwork engine super-level. 5
Starting from the question for an integrated treatment of structure and process perspectives in modeling collaborative systems, we have presented our Sonar approach. It provides a way to capture the whole context of team-oriented process management: from the underlying organizational structure over team formation up to process execution by the team. The accompanying models are rather high-level and illustrative but at the same time they are rich enough in order to generate executable models and other kinds of code that together form the core of the Mulan4Sonar middleware implementation for team-oriented process management.
Regarding our future research efforts, there is a range of topics that we and other people from our research group are working on.
– Collaborative Agent Platform (deployment): Our group has the long-term
goal of developing an agent-based platform for computer-supported
collaboration. We envision Sonar-based organizational models to be used for
specific teamwork applications on top of the platform as well as for supporting
the infrastructure of the platform itself, managing the various platform tasks
and processes.
– Self-organization: Instead of the manager from Figure 1 we promote an
alternative approach where a Sonar model has multiple management levels
and the team processes on one level lead to the transformation of the
specifications of the lower levels, cf. [