Coordinating large distributed relational process structures

Several approaches enabling business process management (BPM) advocate to represent business processes as collections of interacting, interdependent processes. Examples include the artifact-centric and object-aware approaches to BPM [23, 26, 32], where the collaboration of artifact/object lifecycle processes forms an entire business process. Fundamental challenges of these data-centric approaches are to determine which processes exist and how they relate to other processes, as well as the coordination of the resulting structure of interdependent processes. Recently, the relational process structure [39] and coordination processes [38] have been proposed to tackle these challenges. A relational process structure captures processes and their relations in a hierarchical construct, which is then used by a coordination process to specify and enforce coordination constraints. This allows the interactions of different processes to be guided toward a meaningful overall business process.

The coordination of a multitude of different, interdependent processes is a complicated and challenging endeavor [30]. Processes and their relations have to be identified and, based on these connections, suitable coordination constraints need to be specified and enforced. A coordination constraint then denotes a dependency that exists between two or more processes [38]. A coordination constraint usually takes the form of a plain-text statement, e.g., “An application may only be created as long as the corresponding job offer is published,” though formal representations are possible as well. The different processes and their relations are summarized under the term relational process structure. Generally, approaches for coordinating process structures that consist of multiple process types advocate the use of a single entity with the purpose of coordinating all involved processes. This entity is called a central coordinator.

The following section gives an overview over the context and basic conditions in which decentralization and distribution can be used and established with the method presented in this paper.

Object-aware process management is an comprehensive approach for managing data-centric processes [26]. The core of object-aware process management is presented as a meta-model in Fig. 5. Object-aware process management describes business processes in terms of interacting processes, e.g., object lifecycles, with the goal of providing better support for data and better flexibility. The business process only emerges through interactions between processes, and this requires coordination for guiding the business process toward a meaningful goal. Note that the meta-model only contains the concepts relevant for this paper.

The coordination approach of object-aware process management consists of three concepts: relational process structures capture and track process types and their relations. Semantic relationships use these relations for describing constraints for coordinating the interactions between processes. Coordination processes are used for concretely specifying semantic relationships and enforcing these constraints at run-time, relying on the information provided by the relational process structure. Moreover, for obtaining only the relevant information coordinating the processes, these processes are abstracted using a state-based view.

Coordination processes and their related concepts rely on a strict distinction between design-time and run-time entities. A design-time entity is designated as a type (formally superscript\(^{T}\)), whereas run-time entities are instances (formally \(^{I}\)). For the sake of brevity, when referring to entities, e.g., processes, without a type or instance superscript or word member, this means that a statement applies to types as well as instances. By convention, instances are created by instantiating a type. The dot (.) represents the member access operator. The symbol \(<:\) signifies the subtype relation, i.e., x is a subtype of y is written as \(x<:y\). Also by convention, any set is denoted by a capital letter, whereas an element of the set is denoted with the same lowercase letter and vice versa. The concepts that constitute and support a coordination process are inextricably linked to each other, which necessitates mutual references and forward references in the formal definitions for completeness. The formal definitions mirror the implementation of the concepts and do not contain cyclic dependencies, but simply mutual references for navigating the resulting graph. Consequently, formal definitions may mention concepts and entities that will only be defined later in this section. Still, the introduction of concepts and entities follows a logical top-down manner despite the forward references. The intention is to keep this background section as concise as possible while still conveying the essential information. The (mutual) references are implicitly resolved using a globally unique identifier (GUID) for each entity. Furthermore, as this article is part of a larger body of work in context of the PHILharmonicFlows project, the formal definitions are kept consistent in every article.

For the purposes of this paper, a process (cf. Definition 1) is represented in an abstract, simplified manner, which is called a state-based view [37]. In a state-based view, each process model is partitioned into different states that are relevant for process coordination.

Coordination processes originate in the object-aware business process management approach. While objects and their lifecycles have provided the initial motivation for coordination processes, the object and lifecycle model itself is not a prerequisite for coordination processes to work. Therefore, a generalized notion of process \(\theta _{priv}\) is used that may represent, in principle, any kind of process model specification. For the purposes of coordination processes, the paradigm and modeling language in which processes are specified is unimportant. Consequently, a process \(\theta _{priv}\) may be an object-aware process or a process that is specified using BPMN 2.0 [34]. Due to the arbitrary nature, no formal definition of \(\theta _{priv}\) is possible. In every case, a state-based view \(\theta \) provides an abstraction level over the actual process specification \(\theta _{priv}\) [37] that a coordination process uses. Thereby, the process to be coordinated is partitioned into different states that provide significant meaning for process coordination. State-based views enable a coordination process to be paradigm-agnostic, i.e., processes from any paradigm or even different paradigms may be coordinated. This applies to both type and instance levels.

State-based views partition a process specification into distinct and non-overlapping states (cf. Definition 3). A state-based view \(\theta \) is an abstraction over \(\theta _{priv}\), i.e., the actual process specification, mapping elements of \(\theta _{priv}\) to states of the state-based view so that each element (e.g., an activity) belongs to exactly one state (cf. Fig. 6) [37]. States are used to indicate the progress of the underlying process \(\theta _{ priv }\).

States \(\sigma \) are connected with directed edges \(\tau \) denoting state transitions. At run-time, an active state \(\sigma _{a}\) of a process signifies its current execution status; the active state is determined by \(\theta _{priv}\), e.g., the currently executed activity is mapped to \(\sigma _{a}\). Only one state \(\sigma \) may be active at a given point in time. As a consequence, branching state transitions categorically implement an exclusive choice semantics, i.e., states may be mutually exclusive regarding activation. Note that this does not prohibit parallel execution of activities, as parallelism may still occur within a state. As only one state may be active, in case of mutually exclusive states, non-active states are denoted as skipped. Furthermore, state-based views may include backward transitions \(\psi \) that allow re-activating a previous state \(\sigma \), i.e., \(\sigma \) is a predecessor of the current active state \(\sigma _{a}\). Figure 6 shows state-based views of the processes occurring in Example 1.

States and their transitions are, by default, the only entities that are publicly visible to an outside observer of a process. The state transitions \(\tau ^{I}\) and the active state \(\sigma _{a}^{I}\) are driven by \(\theta _{priv}^{I}\). Despite the simplistic specification, state-based views capture the essentials of a process in regard to process coordination. In addition, if desired, state-based views may introduce additional process properties, e.g., specific data attributes that may subsequently be used for process coordination.

Generally, processes may be interconnected by relations. A relation represents a connection between two processes, indicating one or more dependencies between them, i.e., multiple coordination constraints can be defined over the same relation. A relation type (cf. Definition 4) and relation instance (cf. Definition 5) are defined as follows:

Note that relation instances always have exactly one source and one target process instance, as one-to-many or many-to-many relationships are comprised of multiple relation instances \(\pi ^{I}\) (cf. Fig. 7). In particular, two processes may be related by a transitive relation, i.e., a path of relations exists connecting one process with another. Contrary to, for example, Entity-Relationship-Diagrams, relations are directed. This has various purposes, among them the definition of semantic relationships (cf. Sect. 3.2). For any process type or instance \(\omega \), two sets are maintained in regard to relations: \(\varPi _{in}\) is the set of incoming relation instances for a process instance \(\omega ^{I}\) , i.e., \(\varPi _{in}=\{\pi \,|\,\pi .\omega _{target}=\omega ^{I}\}\), and \(\varPi _{out}\), which is defined analogously for outgoing relation instances. These sets allow realizing some efficiency optimizations in coordination process execution and are therefore mentioned for accuracy [39].

Coordination processes possess the technical capability to be employed in a decentralized fashion by design. However, additional concepts are required to effectively realize Stage-1 and Stage-2 Decentralized Coordination. In regard to establishing Stage-1 Decentralized Coordination, the baseline is as follows: A coordination process model \(c^{T}\) represents coordination constraints between process types in terms of (multiple) semantic relationships \(s^{T}\). The process types \(\omega ^{T}\) to be coordinated and their relations \(\pi ^{T}\) are captured in a relational process structure \(d^{T}\). Furthermore, a coordination process \(c^{T}\) is always attached to a process type, which is then denoted as a coordinating process type \(\omega _{ coord }^{T}\). The “coordinating process type” property meets the criteria for Stage-1 Decentralized Coordination. Consequently, coordination processes already represent Stage-1 Decentralized Coordination, as they are instantiated together with the coordinating process type \(\omega _{ coord }^{T}\). A central coordinator (i.e., Stage-0 Decentralized Coordination) can be realized by instantiating a coordinating process type only once, with one coordinating process type per process structure, i.e., it holds \(|[\omega ^{T}|\exists c^{T}.\omega _{ coord }^{T}=\omega ^{T},\omega ^{T}\in d^{T}]|=1\). In the following, it is shown how further decentralization can be achieved with coordination processes, i.e., how Stage-2 Decentralized Coordination can be realized.

In principle, any process type in a relational process structure \(d^{T}\) may become a coordinating process type \(\omega _{ coord }^{T}\), i.e., there may be as many coordination processes \(c_{i}^{T}\in C^{T}\) as there are process types \(\omega _{i}^{T}\in \varOmega ^{T},|C^{T}|\le |\varOmega ^{T}|\). Whether this is actually a reasonable decentralization is an entirely different matter. As such, in principle, a relational process structure \(d^{T}\) may be coordinated using multiple coordination processes \(c^{T}\), establishing a prerequisite for Stage-2 Decentralized Coordination. However, just creating multiple coordination processes does not result in a meaningful overall process coordination that leads toward the particular goal of the overall business process.

In general, when coordinators are decentralized, one of the primary challenges concerns coordination responsibility, i.e., deciding which coordination process \(c^{T}\) shall be responsible for which processes \(\omega ^{T}\). If this remains arbitrarily defined, or not at all, detrimental consequences might occur. For example, a process modeler may specify coordination constraints in any coordination process. In consequence, a specific coordination process might not be an obvious choice to look for this particular coordination constraint later on. If a particular coordination constraint needs to be modified, potentially all coordination processes need to be searched for this particular coordination constraint. This problem becomes more pronounced as a process structure grows in size. Ultimately, this results in a process structure and business process, respectively, becoming unmaintainable and confusing to understand. While coordination responsibility is of general concern to any coordinator, this paper is particularly concerned with coordination process responsibility.

In particular, coordination processes may comprise coordination constraints for several processes, i.e., they enforce the same or different coordination constraints on the same set of processes. Consequently, it is crucial that multiple coordination processes do not model contradicting constraints, e.g., a combination of constraints stating exactly the opposite of another constraint. With decentralized coordinators, this challenge gains importance as coordinators are modeled individually, i.e., contradictions may not be spotted easily. Consequently, the relational process structure offers a way to address this challenge, i.e., avoiding the possibility for contradictions altogether by clearly defining the responsibility of each coordinator. Furthermore, this includes that there is little to no overlap between the individual responsibilities of each coordination process. A particular process type should clearly be the responsibility of one coordination process, not of multiple.

The fact that relations in a relational process structure are directed offers a fundamental building block for creating a solution for defining coordination process responsibilities. The directed relations imply that processes can be arranged hierarchically. This hierarchy is an integral part of how semantic relationships work, the cornerstone of the coordination process concept. Additionally, the hierarchy of a relational process structure offers advantages when using multiple coordination processes for coordinating the processes in a relational process structure.

Having decentralized coordination processes across different hierarchy levels yields significant benefits for the simplicity of the coordination process models. However, a factor that might significantly influence subsidiarity and Stage-2 Decentralized Coordination of a plethora of processes has not been discussed yet: The influence of distributed environments.

In settings where multiple processes collaborate to achieve a business goal, it is not unreasonable to assume that these processes may not all be executed on the same machine. Instead, processes may be executed on a multitude of different machines or servers, i.e., a distributed environment. With the advent of cloud computing, distributed applications are gaining even more momentum, as scalability is becoming an important issue [2, 4].

The PHILharmonicFlows project has developed a hyperscale process engine, called PHILharmonicFlows, that allows distributing processes horizontally across different computational nodes [2]. This enables superior performance in executing processes by leveraging the computing power of entire computational clusters. Consequently, the problem of executing relational process structures in a distributed environment is of considerable practical importance. Especially regarding large process structures, coordination processes might become a bottleneck if the distributed environment is not properly taken into account

In detail, processes in a relational process structure may not all belong to the same (computational) node, e.g., a single server. In a distributed cluster, e.g., a cloud environment, there exist multiple nodes. Different processes may be assigned to different nodes. The distributed nodes may exist for different reasons, possible examples include different physical locations each being represented by a node, or simply multiple servers in the same company department or cluster. Figure 18 shows a schematic view how the different stages of decentralization and distribution fit together.

Consider the following example of a car manufacturing process, which exemplifies a distributed approach to a business process that produces a car (cf. Example 14).

Figure 19 shows a graphical overview of nodes, processes, and assignments of the processes to the nodes. The assignment of processes to nodes can have an impact on the optimal approach for reaching Stage-2 Decentralized Coordination. When choosing where to create decentralized coordination processes, the layout of clusters and nodes as well as the process assignment, must be taken into account.

In regard to process coordination in distributed environments, performance and scalability are the main challenges in addition to correct coordination. Specifically, communication between processes and, consequently, communication between nodes has an important impact on the overall performance of the distributed relational process structure. In general, communication within a node is considered cheap, whereas communication between nodes is costly in terms of time and performance. This holds regardless of any specific metrics, and communication between nodes should therefore be reduced to a minimum. Costly extra-node communication is showcased by Example 15.

Obviously, communication between nodes cannot be totally avoided, as processes need to be coordinated across nodes. Coordination processes, however, allow minimizing the communication between nodes significantly. By attaching coordination processes to process types where the scope encompasses the entire node, the communication is kept within a node, as exemplified by Example 16. Note that further coordination processes within a node are still possible by using additional coordination process types for Stage-2 Decentralization within the node itself (cf. Fig. 18).

As shown with Examples 15 and 16, distributed environments may have a huge influence on the appropriate decentralization of process coordination. Taking the layout of clusters and nodes into account when modeling multiple coordination processes increases the overall benefit offered by a decentralized approach, allowing for optimal process coordination.

Altogether, coordination processes allow for the decentralized coordination of large process structures. The relational process structure hierarchy, scope, and subsidiarity principle provide clear responsibilities for each coordination process, facilitating modeling and reducing modeling errors. In particular, the coordination approach no longer contains a single point of failure. By using multiple coordination processes for the same large process structure, the individual coordination process models become smaller and simpler, resulting in greater understandability and maintainability of the models. As shown, these advantages also translate well to a distributed cluster, where a coordination process can be used for each node, significantly reducing communication overhead and, therefore, increasing the performance of executing the processes.

Coordination processes have originated in the object-aware process management paradigm [26]. The concepts of object-aware process management, i.e., objects, lifecycles, relations, and coordination processes, have been implemented in the PHILharmonicFlows prototype. A lifecycle process of an object conforms to the definition of process type (cf. Definition 1).

The initial prototypical implementation of PHILharmonicFlows as an object-aware process management system was developed from 2008 to 2012. It involved functional design- and run-time of the basic concepts of object-ware process management, though many advanced features could not be realized due to the technology available at the time. In 2015, a fully new implementation internally named “Proteus” was started, leveraging the emerging concepts of microservices. Microservices allow for a scalable and performant execution of object-aware processes. However, this also rendered almost all of the existing codebase of the previous prototype obsolete. The new paradigm of microservices also required to re-think and adapt many concepts of object-aware process management, accounting for the new requirements imposed by this fundamental change. Concepts such as object lifecycles [41], the relational process structure [39], and coordination processes [38] were extended and adapted, with a major focus on the run-time. In particular, the operational semantics required a substantial overhaul. The re-implementation of PHILharmonicFlows also paved the way for the development of advanced features such as ad hoc changes for object aware-process management [3] and a hyper-scalable run-time environment [2] and enabled the concepts Decentralization and Distribution of process coordination, as presented in this article. This new and improved microservice-based implementation continues using the branding PHILharmonicFlows.

Both distribution and decentralization are inherently relevant to the object-aware process management paradigm in particular, but also to other data-centric approaches to BPM [42]. As business processes emerge from potentially large relational process structures containing interacting objects with lifecycles, decentralization of process coordination yields significant benefits. PHILharmonicFlows, the implementation of the object-aware paradigm, comprises a distributed process engine based on microservices, and may be deployed to a cloud-based cluster. As such, multiple coordination processes have significant benefits as well. The intention is to show that, in addition to the functional benefits of having multiple coordination processes, it also yields significant performance improvements, even when there is no distribution over multiple nodes.

Most approaches to business process management that rely on interacting processes are closely related to data-centric process management paradigms [42]. As they primarily rely on process interactions, they may therefore also be classified as interaction-centric approaches in addition to being data-centric.

Proclets are small, lightweight processes that focus on interactions between processes [44, 45]. As one of the first approaches, proclets abandoned monolithic process models in favor of multiple, interacting processes. Proclets are defined using the well-known formalism of Petri nets. The approach also recognized that instances of proclets may need to communicate with more than one other proclet. Therefore, the proclet approach supports one-to-many interactions between proclets. For this purpose, the used Petri net formalism is extended with ports, enabling communication with other proclets. Ports are fully integrated into the Petri net formalism, supporting the formal analysis techniques known from standard Petri nets. The communication between proclets goes over channels that connect to ports on other proclets.

The actual communication between proclets over a channel is realized by performatives, a special form of message. A major advantage of the proclet approach is the support for the full range of formal analysis techniques enabled by Petri nets. Proclets have the potential to form large interconnected structures of different proclet types. However, interactions between proclets are coordinated by the individual proclets themselves, using performatives. As Proclets coordinate with other proclets individually in a one-to-many fashion, no concept for separate coordinators exists. Furthermore, no specific research regarding decentralization of individual proclets or coordinators is known.

Artifact-centric process management [33] describes business processes as interacting artifacts. The behavior of artifacts is expressed in lifecycles. Central to this approach is the artifact, which holds all process-relevant information in an information model. An artifact lifecycle is specified using the Guard-Stage-Milestone (GSM) meta-model [22, 23]. In general, an artifact may interact with other artifacts. However, GSM does not provide dedicated coordination mechanisms or explicit artifact relations, contrary to the object-aware approach presented in this paper. Instead, GSM incorporates an arbitrary information model as well as an expression framework with which artifact interactions may be specified. While this, in theory, allows expressing any concept or constraint, in practice many of the capabilities of artifact-centric process management hinge on the power of the expression framework. As a drawback, expressions might become very complex and must be supported by a rule engine to realize the full potential of artifact-centric process management. In principle, the concepts of the relational process structure and the semantic relationships may be recreated in GSM with complicated expressions to realize at least the basic functionality of coordination processes. While this is not impossible, it requires great effort on part of the modeler to achieve the same functionality as object-aware process management provides out-of-the-box.

Artifact-centric process management has been prototypically implemented in the BizArtifact demo tool⁷, whose predecessors include Barcelona [20] and Siena [12]. Due to the complexity of an artifact-centric business process, model verification [6, 8] constitutes an important aspect of artifact-centric process management. Moreover, several variants of artifact-centric process management exist in regard to coordination.

Artifact-centric hubs [21] constitute one of the first ideas to allow collaboration using artifacts. However, the interactions take place between process participants, not among the artifacts themselves. The basic idea is that participants use artifacts to interact with each other, where an artifact is similar to a bulletin board. [27] reused these ideas that lead to the creation of artifact-centric hubs, but instead used these ideas for introducing an approach enabling artifact choreographies. Process participants, called agents, use artifacts and execute them. Artifacts are assigned to a specific location. By knowing where artifacts are located and who is using them, a choreography between these agents can be automatically generated. While both [21] and [27] provide approaches for managing interactions, the interacting parties are not the artifacts themselves. Instead, choreographies between participants are created, a stepping stone to artifact-based cross-organizational business process. Consequently, both approaches are not directly comparable to coordination processes. Moreover, using artifacts in a large-scale setting has not been investigated by artifact-centric process management. As the artifact-centric hubs are supposed to be centralized, no decentralization or distribution concepts have been investigated.

In contrast, [43] presents an approach for providing declarative choreographies for artifact-centric processes where artifacts and not participants are the interacting entities. The artifacts in this approach use a type-instance schema as well. Declarative choreographies recognize the need for explicitly knowing the relations between artifacts and their multiplicity. Consequently, one-to-many relationships and many-to-many relationships are supported by a concept called a correlation graph. The artifact instances are coordinated using messages, which are exchanged based on the constraints of the declarative choreography. The constraints are specified by using expressions, where the expressions require greater expressiveness than the expressions used for semantic relationships. In turn, this makes expressions for artifacts more complicated in comparison. Similar to [21], decentralized or distributed coordination of artifacts has not been a specific concern, though decentralization and distribution are of interest for the approach in principle.

[18] investigates many-to-many interactions between processes. The need for supporting many-to-many relationships when dealing with interactions between artifacts is recognized. Artifact lifecycles are specified by using Petri nets, specifically proclets, instead of GSM, with the intention of using the formal properties of Petri nets to verify an entire artifact-centric business process [17]. Many-to-many interactions between processes are fully incorporated into the Petri net descriptions of these processes [44, 45]. The interactions between different Petri net-based processes are expressed in terms of correlation and cardinality constraints, and full operational semantics are provided. This form of description is accessible for formal reasoning and verification. As opposed to coordination processes in object-aware process management, which aim at high-level abstractions for different concepts by using specialized notations, [17, 18] aim at notational simplicity by restricting themselves to few syntactical concepts, i.e., Petri nets only. Similar to Proclets, dedicated coordinators do not exist.

The coordination of large process structures with a focus on the engineering domain is considered in [30, 31]. The COREPRO approach explicitly considers process relations with one-to-many process relations and dynamic changes at run-time, but transitive relations are not covered. In comparison with COREPRO, semantic relationships are similar to external state transitions of a lifecycle coordination model. However, the external state transitions do not take the semantics of the respective process interaction into account. While COREPRO considers large-scale application of its specific modeling concepts, no specific investigations into decentralized coordination have taken place.

In principle, artifacts and proclets can be used in a distributed environment. Conceptually, no coordinator, similar to the coordination process concept, is present in these approaches. Consequently, no research toward decentralized process coordination may be found in the literature. Furthermore, distribution of proclets or artifacts has not been investigated as well.

As PHILharmonicFlows comprises an execution engine capable of supporting decentralized processes and coordination processes, it is necessary to assess other process engines. [36] shows that most decentralization efforts in BPM are achieved based on process engines, but not individual processes or coordinators. In this regard, PHILharmonicFlows and its hyperscale process engine are far ahead. Other types of decentralization take place on the task level, where individual tasks of a single process instance are executed on different nodes.

[15, 16] and [10] distribute workloads of business processes between a client-side engine and a cloud-based engine, taking into consideration that users might not want to store their business data in the cloud. The approaches suggest to primarily run compute-intensive workloads on the cloud-based engine and transfer business data only when necessary. [15] further presents a method for decomposing the process model into two complementary process models: one for the client engine and one for the cloud engine.

[24] deals with very large workflow engines and presents concepts to provide high availability of the engine. The counteract failing workflows, a backup strategy is presented. The backup allows resuming a particular process instance at any point in their execution.

[7] presents concepts for the executing processes in a distributed environment. The paper presumes a cluster with different nodes, and each node has a workflow engine server. Workflows may be transferred between nodes to achieve optimal performance, though individual servers may become overloaded. The approach replicates workflow engine server within nodes of the cluster to achieve more performance by evenly distributing computing load within the node.

With coordination processes, the conceptual, technical and methodological capabilities exist to successfully implement decentralized process coordination for large process structures. The concepts of scope, hierarchy of the relational process structure, and the principle of subsidiarity decrease complexity and, thus, make the entire approach feasible. On the benefits side, large-scale coordination of large process structures becomes feasible, while at the same time the complexity and size of individual coordination process models are reduced compared to a central coordinator. As has been shown, this also applies to distributed relational process structures. However, in a different sense multiple coordination processes are more complex than a central coordinator. Again, subsidiarity and hierarchy are central to manage this complexity, enabling designers to model the coordination of large process structures. Furthermore, it has been shown that decentralization of processes and process coordination has performance advantages compared to central process coordination. Through state-based views, the concepts presented in this paper can, in principle, be transferred to other paradigms, given these paradigms can conform to the concept of a relational process structure.

While coordination processes can already deal with a vast number of coordination problems, there are still several areas left for improvement. One challenge concerns the monitoring of a business process which is constituted by interacting, interdependent processes. Coordination processes may be used to gain valuable insights into the overall progress of the business process, as coordination processes may be used to aggregate status information from the coordinated processes. This is especially challenging when decentralized and distributed coordination processes are involved, but offers promising perspectives as well. Decentralized process coordination, in principle, allows for the decentralized monitoring of related process instances, enabling a more fine-grained view of the progress.

Currently, PHILharmonicFlows offers some practically oriented verification for single coordination processes. Expanding this verification to include decentralized coordination processes is immensely beneficial to a designer. Regarding theoretical concepts such as controllability and realizability, significant contributions have been made for choreographies of activity-centric processes [13, 19, 25, 27, 28] and artifact-centric processes [5, 6, 8, 14]. As coordination processes are based on semantic relationships, it is unclear how these results translate to coordination processes and in particular to decentralized coordination processes. A thorough investigation into the applicability of these results to coordination processes is the subject of future work.