Collaborative Business Process Lifecycles

Philipp Walter, Dirk Werth

Institute for Information Systems at DFKI, Saarbruecken, Germany

Abstract. Business process lifecycle management is established for the con-

tinuous improvement of internal business processes that do not exceed company

borders. Therefore, the concept could also be applied to enhance collaborative

business processes spanning over multiple enterprises. In contrast to the intra-

organizational case, lifecycle management of cross-organizational collaborative

processes imposes several organizational and technological challenges that re-

sults from the multiple-independent-actors-environment of collaborations. In

this article, we address these challenges and present a conceptual solution for

the different phases of this lifecycle. Finally, we propose a technical architec-

ture that prototypically implements these concepts.

1 Introduction

Nowadays, economic organizations are dramatically changing towards networked

structures [15]. These are characterized by core competence specialized value units

[17] that intensively interact along the added value in order to together generate the

intended product. This intensification of exchanges leads to strong, collaborative

relationships (also called collaborative business, cf. [18]). Thus the ground is prepared

for enterprise networks and virtual organizations [5]. Such collaborations are mainly

driven by the intention to generate added value. This generation is performed through

synchronized execution of associated business tasks. This sequencing of activities

constitutes a collaborative business process.

Collaborative business processes are a special kind of (conventional) business

processes. However, they imply special properties that strongly differ from the regular

case. First, they are spanning over multiple organizations, because the generation of

added value is performed through cross-organizational division of labor. Second, the

individual business activities that compose the process clearly belong to a unique

organization. Thus, having groups of activities that are processed in a direct sequence,

we can state that the collaborative business process is partitioned into a set of these

parts where each part is distinctly associated with an organization. This organization

fully controls this part in the sense that it independently executes, administrates and

manages it. Therefore those parts of cross-organizational business processes can be

characterized as autonomous fragments.

Hence collaborative business processes strongly differ from intra-organizational

ones. Consequently concepts and solutions that are developed for the regular case are

in most cases not suitable for cross-organizational purposes. In this article we investi-

gate the aptitude of the business process lifecycle concept for collaborative environ-

Walter P. and Werth D. (2006).

Collaborative Business Process Lifecycles.

In Proceedings of the 1st International Workshop on Technologies for Collaborative Business Process Management, pages 84-95

 SciTePress

ments. After showing the gaps within the ‘classic’ lifecycle concept, we propose a

platform which is apt to support the lifecycle for cross-organizational business proc-

esses. In the following sections we will present the conceptual and technical basics of

this platform. In contrast to other approaches [9] we not only focus on bilateral proc-

essing of business processes, but on end-to-end processes. Therefore, we will step

through the three phases of the cross-organizational Business Process Lifecycle and

show the concepts we developed for every phase. Afterwards we will show how the

concept is realized so far and finish with a short outlook.

2 The Business Process Lifecycle in Collaborations

Designing business processes is only the first step of a continuous and successful

business strategy, since the design results in static models of the considered processes

which do not change over time. Execution of these static models usually yields im-

provement potential over time, e.g., because the execution context changed or certain

execution aspects were not reflected in the model. To realize and quantify these im-

provement potentials, it is necessary to measure execution of the models, i.e., perform

controlling of them, which allows for identifying weaknesses and changing the mod-

els accordingly.

The Business Process Lifecycle shown in

Fig. 1 integrates this approach into three

steps: business process design, business process implementation and business process

controlling [21]. The basic lifecycle concept can be found in the House of Business

Engineering [20; 22]. Business process design refers to modeling of existing as-is or

intended to-be processes. This can be accomplished using modeling languages (e.g.,

EPC [10], BPML [2]) and the respective modeling tools. Business process implemen-

tation summarizes all operative steps that are necessary to execute a process which

was modeled before. Apart from IT systems used for execution, this explicitly in-

cludes human interaction as well. Among the technical means for process execution

are or example ERP systems and workflow engines. Research effort is currently put

into the exploration of mechanisms to minimize the need for human interaction in

business process implementation. Business process controlling denotes all actions that

aim towards measurement and examination of running and finished processes with the

Fig. 1. Business Process Lifecycle.

goal of discovering optimization potentials. Once found, such a potential can be real-

ized by changing the process model in the modeling phase of the next cycle pass.

This lifecycle is conceived for a single organization. In the design phase, each

process model is changed by a single modeler at a time. During the execution phase,

the process is handled by a single execution system within a single organization. Con-

sequentially all controlling information can be gathered “indoor”, i.e., within the or-

ganization. However, in environments with multiple organizations acting coopera-

tively, collaborative processes cannot be regarded as monolithic anymore, since dif-

ferent parts of them are designed, executed and controlled by different organizations

[13]. Consequently the lifecycle abruptly gets very complex and difficult to handle:

• The design (respectively modeling) task comprises multiple autonomous modelers

that act independently and follow different goals. This results in self-contained

parts of the collaborative business process. Therefore the process design can rather

be characterized as an assembly task of autonomous process parts.

• The execution is distributed over different enterprises. Consequently there is no

central processing engine. Instead each autonomous process part has its own inde-

pendent processing engine, so classic workflow concepts and technologies have to

be extended to match the new cross-organizational requirements [24].

• Controlling means monitoring of running and finished processes and comparing

them with set values. However, monitoring in the sense of determining unique

process states is impossible for collaborative workflows, because their state is hid-

den in the autonomous workflow engines. They only disclose virtual state informa-

tion that clouds the real procedures. Moreover, the controlling comprises the ag-

gregation and calculation of valuation functions. However, these functions contain

information on business structures (esp. cost factors). Such information is consid-

ered business-critical and inaccessible to third parties, even if they are partners.

Having revealed these gaps, we will step through these three phases and show the

concepts for collaborative business processes in the next section.

3 Conceiving a Cross-Organizational Business Process Lifecycle

Transferring the concept of lifecycle-based business process management to cross-

organizational environments requires the shift from a centralized paradigm to a sup-

port for distributed environments. The different life-phases of these kinds of business

processes are namely characterized by the involvements of different actors. For these

a collective behavior cannot be supposed [19]. Thus each phase requires new tech-

niques that are different to those of the classical business process management and

that incorporate the splitted activities. Therefore we do not focus on bilateral process-

ing of business processes, but on end-to-end processes with potentially a huge number

of contributors.

Distributed Business Process Modeling. The design of business processes is consid-

ered one of the fundamental management tasks. In order to document the design, a

specification medium is needed. On the conceptual level models have raised as the

primary medium for business process specifications (e.g. EPC, BPML, BPEL, etc.).

Thus the design task can be summarized as the creation of business process models.

With regard to cross-organizational business processes, this actually comprises the

model generation for an original that spans over multiple organizations. In principle

this can be performed in a centralized and a decentralized way:

• Supposing a centralized model creation, a single actor (that may also be incorpo-

rated by a group of collectively acting individuals) is in charge of the whole proc-

ess model. This implies detailed knowledge of and unrestricted access to all as-

pects of the process through all organizations. Due to the individual demand of

protection, real-world organizations usually do not agree to fully expose their

knowledge and their processes to a third party. So this case can be considered im-

plausible.

• Assuming a decentralized model creation, this implies the existence of different

modeling individuals, each of which generates only parts of the process. Within

this procedure they may follow different modeling paradigms, methods and lan-

guages. Therefore this approach requires both a technique for assuring the consis-

tent individual model creation and a technique for the integration of the partial

models.

Although from a theoretical perspective, a suitable approach has to cope with all

potential method permutations, our approach is limited to a homogeneous approach,

i.e., we presume the use of a single modeling language. Even in this scenario exist

sufficient degrees of freedom for the modeling subject. In our implementation the

event-driven process chain (EPC) language is used. Since EPC is one of the most

common process model languages (at least in Europe), this seems to be a suitable

assumption.

Many approaches follow a top-down modus operandi for modeling cross-

organizational business processes (eg. [1]). Foundation for this procedure is a blue-

print model (a.k.a. reference model) of the cross-organizational business process

which is to be implemented by the different participants. In a second step, each of

them must adapt his processes according to the blueprint. However, if we postulate

independent organizations, this forced adaptation mechanism contradicts with the

autonomy property, i.e., that they are legally independent and acting on their own

behalf exclusively. The presupposition of independent organizations fits most real-

world collaboration scenarios, so the modeling procedure must not interfere with the

autonomy of the individual organizations.

Therefore we follow a bottom up approach which founds on existing process capa-

bilities. They are encapsulated in modules from which a new business process is

composed. The main advantage of this approach is the elimination of the need to

adapt. The individual actor can incorporate its readiness to adaptation within its mod-

ule design instead. More precisely, the design procedure comprises four steps:

1. Definition of process modules:

In contrast to the top-down approach described above, we start with the assessment

of the status quo of the different organizations involved by specifying their capa-

bilities. In our case they have to express their ability to produce output using proc-

ess models that describe their possible processing sequences. The results are com-

ponent-like models that can be assembled together and that incorporate process in-

terface descriptions specifying interaction points.

2. Definition of process intentions:

The way the process modules above are composed is not arbitrary – the intended

overall business process has to follow certain business objectives. In order to con-

struct an objective-adequate process model, the intention of this process must be

defined. This especially addresses the output the process has to deliver as well as

the organizational constraints (e.g., the whole process has to be performed within

the EU).

3. Process module composition:

The composition itself is performed by analyzing compatibility of process interface

pairs. That yields pairs of matching interfaces through which process modules can

be connected. Based on those modules which are able to produce the intended out-

come, a network of modules is successively constructed. The procedure finally re-

sults in a set of modules that generate the final product. Thus the composition is di-

rected by the matching assignments of the process interfaces. The set is filtered by

the organizational constraints of step 2 and rated by a common target function. The

best rated result is the final one and describes a common cross-organizational busi-

ness process model for all participants.

4. Process model consistency analysis:

To avoid contradictions within the overall process model, we close the composition

phase with a consistency analysis during which the model is analyzed with respect

to flow logic consistency. Such a test is described for example in [27]. Having

passed this test, the cross-organizational business process model can be realized

within all involved organizations.

Distributed Business Process Execution. Starting point for the distributed execution

of a business process is a common process model that all participants share and that is

business oriented, i.e., its content is mainly conceptual and its purpose is organiza-

tional management. From this model every participant extracts those parts that he has

to execute and augments them with arbitrary information he needs for execution, e.g.,

refinements of process sub-parts or execution context parameters (cf. Fig. 2). Thus the

business model is transformed into an IT-oriented workflow model, the main purpose

of which is the execution of the contained process. We will now introduce the steps

from the common process model to execution of the workflow model:

1. Splitting Up the Common Process Model:

All activities in the common process model are annotated with the executing or-

ganization unit (“Company X”), or with an organization unit role (“Customer”)

that can be mapped onto a concrete actor within the execution context. So the

common model disaggregates in disjoint process model fragments that are exe-

cuted by exactly one actor each. Because the process modules, which were com-

posed to the common process model during the modeling phase, have interface de-

scriptions, it is possible to define exactly which goods and which information must

be transferred from one actor to another.

Apart from goods and information, the execution of the whole process devolves

from one actor to another at an interface. Therefore it is necessary to define how

the control of the process is transferred. At process junctions it may be even possi-

ble to split up process control or join multiple execution threads again.

a single organization. However, the transfer of process execution control and con-

text via push and pull mechanisms is not common. Especially in split and join

situations, e.g., when a simultaneous execution of multiple process parts on multi-

ple systems begins or finishes, the process context must be duplicated and merged

accordingly. During execution, performance data is gathered as a means for the

next lifecycle step: the controlling phase.

Distributed Business Process Controlling. From the management perspective, the

ability to execute a business process is not sufficient. To enable the ability to improve

the design and the way of execution, it is mandatory to be able to measure the target

object, i.e., to reveal performance indicators of the cross-organizational business

process. In the intra-organizational case, this means to extract historical execution

information from a single process execution system (mostly a workflow management

system) and to calculate the performance indicators from them. In contrast to that, the

cross-organizational case is rather complicated. On the one hand there are multiple

execution systems, each of which holds only partial information about the execution

of a single cross-organizational business process. Thus the challenge is not only to

compose performance data from multiple sources, but also to identify linked process

chunks and to reconstruct the complete structures of historical cross-organizational

business processes under the side condition of heterogeneous keeping of data and

system ownership. On the other hand this information on the reconstructed process

not necessarily leads to performance indicators for the whole process, because the

calculation of these indicators requires the valuation of process execution data. How-

ever this valuation (e.g., the cost function) is usually considered a business secret, so

an overall indicator processing cannot be performed without exposing individual

Fig. 3. Concept for distributed performance indicator processing.

business knowledge. Therefore we propose to calculate distributed performance indi-

cators in a way equivalent to the execution data processing: each organization trans-

forms the process information gathered from the execution systems into its individual

(partial) performance indicators. These figures will then be used to compute the over-

all indicators. Following this procedure, the organizations are not obliged to publish

their calculation scheme and only communicate the resulting values. Fig. 3 visualizes

this controlling concept.

4 Technical Realization

This section deals with the realization of the concepts presented above. Within the

research project P2E2 – Peer-to-Peer Enterprise Environment

, we developed a plat-

form that prototypically implements the distributed Business Process Lifecycle man-

agement principles presented above.

The basic idea is to form a network of actors (“peers”) which are all equal with re-

spect to rights and what they are able to do [23]. The network is dynamic, i.e., peers

may enter and leave the network at any time.

The peer-to-peer principle guarantees

equal opportunities for all participating parties. Every party distributes models of the

processes that it offers to perform. A customer peer can reassemble these process

fragments to the model of a complete process and buy the execution of it (or parts of

it) from other peers. Thus the P2E2 network structurally corresponds to the organiza-

tional network of the collaborating organizations and therefore provides a wide set of

advantages as a technological base for enterprise networks [11].

Distributed Business Process Modeling. First, the processes offered in the network

must be modeled, aggregated, assembled and so on. The top-level modeling language

used in the P2E2 prototype is the event-driven process chain (EPC). Modeling is

performed using the ARIS Toolset by IDS Scheer AG. However, the P2E2 meta-

model explicitly supports other modeling languages, too.

In the first step, every peer designs his own processes in any desired detail, thus

obtaining a “private” model which can contain arbitrary (even secret) information

about the process and therefore is not shared with other peers. Then he generates a

“public” view to the model by reducing the contents of the private model to the mini-

mum that is necessary for other peers to comprehend the modeled process and its

interfaces.

In the next step, all public models by all actors are distributed among the network.

For this purpose we developed the Process Distribution and Discovery Tool (PDDT),

a peer-to-peer software which is based on the JXTA peer-to-peer framework and

supports distributing, versioning, searching and transferring models. With the shared

information about the available process fragments, any peer can construct a complete

P2E2 is funded under the SE2006 initiative by the German ministry of education and research

(BMBF).

In our project, we assume that changes in the network structure do not occur during the proc-

ess execution.

process from the fragments. Using the PDDT again, this common process model is

shared with all peers that participate in its execution.

Distributed Business Process Execution. Fig. 4 shows the architecture of a P2E2

peer along with the controlling and configuration applications which are not an inte-

gral part of the peer itself. This subsection about execution starts with the output of

the modeling tool in the lower left corner of the figure.

In P2E2, the execution part of the lifecycle is simplified compared to the scenario

outlined in Section 2, because the common process model is composed from several

process fragments. So the responsibilities for the execution of the process parts are ex

ante established and partitioning the common process can be omitted, because the

fragments already exist. The augmentation of the process fragments with execution

information also benefits from the fact that the private model with all execution de-

tails already exists. So it is sufficient that every peer augments its process fragments

once and reuses this information in every execution.

Another part of the augmentation phase is the conversion of all models into a

common execution model language, i.e., XPDL in our case: finally, all P2E2 process

fragments exist as executable XPDL models. To obtain the final XPDL models, a

multi-stage conversion and augmentation is performed. First, the EPC models are

automatically converted into XPDL format using the modeling tool. Then the attrib-

utes of all XPDL model elements are filled in with data necessary for execution using

another tool developed within the project, which is named “augmentation tool” in

Fig.

Execution in P2E2 is finally performed using workflow engines by Carnot AG and

abaXX Technology AG (“WFMS” in

Fig. 4). Whenever necessary, communication

between executing peers is performed by calling BAPI methods using Wf-XML.

Distributed Business Process Controlling. During execution, every engine records

performance data and stores it for the third lifecycle phase: controlling. The most

basic performance data gathered during execution is stored in the audit trails of the

workflow management systems (see Fig. 4). However, mainly due to business se-

crecy, their content is not exposed directly. Instead, every peer processes its perform-

Internet

P2E2 Controller P2E2 Peer

Controlling

Tool

Performance

Data

Process

Catalog

P2E2 Configurator

Modeling Tool

Augmentation

Tool

XPDL

WFMS

Performance

Data

Processing

Audit Trail

Logging

Java API

XPDL

Configuration

Process Moules

P2E2 Peer

Process

Catalog

WFMS

Performance

Data

Processing

Audit Trail

Logging

Java API

BAPI (Wf-XML)

Process Modules

Fig. 4. P2E2 Technical Architecture.

ance data to its liking and exposes the results or parts of the results over a specific

web service interface exclusively. Of course, this information only refers to the exe-

cution of a process fragment, not the process as a whole.

The reassembly from fragments to the whole process is achieved using a specific

controlling tool (see

Fig. 4). It first fetches performance information about process

fragments from all participating peers using the web service described above. Then

the information how the whole process is composed from process fragments is used to

aggregate per-process information from per-fragment data.

5 Related Work

The approach presented tries to bring together several research areas that originally

are addressed isolated. The concept of distributed business processes has raised ten

years ago (eg. [8, 26]). It was mainly driven by distributed system research and tried

to archive the cross-system execution of workflows (eg. [25], [3]). Such attempts also

resulted in the definition of various standards (e.g. WF-XML) to simplify the interop-

erability of workflow management systems (cf. Workflow Management Coalition

1996). But they assume the existence of a single, atomic workflow specification

model (eg. [14]). On the other hand exists various approaches of distributed business

process resp. workflow modeling (eg. [7]). They describe the creation of singular

models by multiple actors. But they mainly miss either the link to the distributed exe-

cution or the interconnection to the controlling task. Especially this task is neglected

in other management approaches to cross-organizational business processes [16, 6,

12].

6 Conclusion and Outlook

In this paper, we have presented a concept for the cross-organizational business proc-

ess lifecycle management, including distributed modeling, execution and controlling,

that is already implemented in most parts. In particular we addressed and ensured the

continuous IT support of all three lifecycle phases, the decision autonomy and secrecy

demand of the participating organizations during all three lifecycle phases, and the

technical and conceptual feasibility of our approach (which will be finally verified

when the entire prototype is completed).

Currently, two business scenarios are evaluated with our concept. One of them is

taken from the financial services sector and deals with factoring, the other one deals

with supply chain management in international and national product distribution.

This concept was developed at the Competence Centre Business Integration

(CCBI), Institute for Information Systems (IWi) at the German Research Center for

Artificial Intelligence (DFKI), Saarbruecken. It addresses current research problems

in the area of process integration and networked businesses by bringing together the

business-oriented and the IT-views. The work is performed by clustering national and

international funded research projects (esp. ArKoS, ATHENA, INTEROP, P2E2),

intending the development of solutions for a better interoperability in business net-

works.

References

1. Adam, O., Chikova, P., Hofer, A., & Vanderhaeghen, D. 2005, "Customer-Driven Process

Management in Value-Added Networks Using an Architecture for Collaborative Business,"

in Proceedings of CollECTeR (Collaborative Electronic Commerce Technology and Re-

search) Europe 2005 - Collaborative Business, Session 2: Customer-Supported Activity

Coordination, A. P. Karduck, ed., pp. 1-9.

2. Arkin, A. 2002, Business Process Modeling Language Business Process Management

Initiative.

3. Bauer, T. & Dadam, P. 1997, "A Distributed Execution Environment for Large-

ScaleWorkflow Management Systems with Subnets and Server Migration," in Proceedings

of the 2nd IFCIS Conference on Cooperative Information Systems.

4. Camarinha-Matos, L. M. 2002, Collaborative Business Ecosystems and Virtual Enterprises

Kluwer Academic, Norwell.

5. Davidow, W. H. & Malone, M. S. 1992, The Virtual Corporation - Structuring and Revital-

izing the Corporation for the 21st Century Harper Collins, New York.

6. Dayal, U., Hsu, M., & Ladin, R. 2001, "Business process coordination: State of the art,

trends, and open issues," in Proceedings of 27th International Conference on Very Large

Data Bases.

7. Graw, G. & Gruhn, V. 1995, "Distributed Modeling and Distributed Enaction of Business

Processes," in Proceedings of the 5th European Software Engineering Conference,

Springer, Berlin et al., pp. 8-27.

8. Graw, G., Gruhn, V., & Krumm, H. 1996, "Support of cooperating and distributed business

processes," in Parallel and Distributed Systems, pp. 22-31.

9. Grefen, P., K.Aberer, Y.Hoffner, & H.Ludwig 2001, "CrossFlow: Cross-organizational

Workflow Management in Dynamic Virtual Enterprises", International Journal of Com-

puter Systems, Science and Engineering, vol. 15, no. 5, pp. 277-290.

10. Keller, G., Nüttgens, M., & Scheer, A.-W. 1992, Semantische Prozessmodellierung auf der

Grundlage "ereignisgesteuerter Prozessketten (EPK)", Universität des Saarlandes,

Saarbrücken, 89.

11. Kupsch, F. & Werth, D. 2004, "Process-Driven Business Integration Using Peer-to-Peer

Technology," in Innovations Through Information Technology, Mehdi Khosrow-Pour, ed.,

pp. 1294-1300.

12. Leymann, F., Roller, D., & Schmidt, M.-T. 2002, "Web services and business process

management", IBM Systems Journal, vol. 41, no. 2, pp. 198-211.

13. Ludwig, H., Bussler, C., Shan, M., & Grefen, P. 1999, "Cross-Organisational Workflow

Management and Co-ordination - WACC '99 Workshop Report", ACM SIGGROUP Bulle-

tin, vol. 20, no. 1.

14. Muth, P., Wodtke, D., Weissenfels, J., Kotz-Dittrich, A., & Weikum, G. 1998, "From Cen-

tralized Workflow Specification to Distributed Workflow Execution", Journal of Intelligent

Information Systems, vol. 10, no. 2, pp. 159-184.

15.

Österle, H., Fleisch, E., & Alt, R. 2000, Business Networking - Shaping Enterprise Rela-

tionships on the Internet Springer, Berlin et al.

16. Pereira Klen, A. A. 1999, "Distributed Business Process Management," in Proceedings of

the IFIP / PRODNET Working Conference on Infrastructures for Virtual Enterprises: Net-

working Industrial Enterprises, Kluwer, pp. 241-258.

17. Prahalad, C. K. & Hamel, G. 1990, "The core competence of the corporation", Harvard

Business Review, vol. 63, no. 3, pp. 79-91.

18. Röhricht, J. & Schlögel, C. 2001, cBusiness . Erfolgreiche Internetstrategien durch Collabo-

rative Business Addison-Wesley.

19. Sandler, T. 1999, Collective Action - Theory and Applications University of Michigan

Press.

20. Scheer, A.-W. 1996, ARIS-House of Business Engineering : Von der

Geschäftsprozeßmodellierung zur Workflow-gesteuerten Anwendung ; vom Business

Process Reengineering zum Continuous Process Improvement, Universität des Saarlandes,

Saarbrücken, 133.

21. Scheer, A.-W. & Jost, W. 2002, ARIS in der Praxis - Gestaltung, Optimierung und

Implementierung von Geschäftsprozessen Springer, Berlin et al.

22. Scheer, A.-W., Nüttgens, M., & Zimmermann, V. 1995, "Rahmenkonzept für ein

integriertes Geschäftsprozeßmanagement", Wirtschaftsinformatik, vol. 37, no. 5, pp. 426-

434.

23. Schoder, D. & Fischbach, K. 2002, "Peer-to-Peer : Anwendungsbereiche und

Herausforderungen," in Peer-to-peer: ökonomische, technische und juristische

Perspektiven, D. Schoder, K. Fischbach, & R. Teichmann, eds., Springer, pp. 3-21.

24. Schulz, K. 2002, Modelling and Architecting of Cross-Organizational Workflows, PhD

Thesis, University of Queensland.

25. Schuster, H., Jablonski, S., Kirsche, T., & Bussler, C. 1994, "A client/server architecture

for distributed workflow management systems," in Proceedings of the 3rd International

Conference on Parallel and Distributed Information Systems, pp. 253-256.

26. van der Aalst, W. M. P. 1998, "Interorganizational Workflows," in Proceedings of the

PROLAMAT 98, pp. 21-43.

27. W.Sadiq & M.E.Orlowska 1999, "Applying Graph Reduction Techniques for Identifying

Structural Conflicts in Process Models," in Proceedings of the 11th International Confer-

ence on Advanced Information Systems Engineering (CAiSE '99), Springer, pp. 195-209.

28. Workflow Management Coalition 1996, Workflow Standard - Interoperability, Abstract

Specification, TC-1012, Version 1.0.