=Paper=
{{Paper
|id=None
|storemode=property
|title=Proposition of a Generic Metamodel for Modeling Interorganizational Business Processes
|pdfUrl=https://ceur-ws.org/Vol-601/EOMAS10_paper4.pdf
|volume=Vol-601
}}
==Proposition of a Generic Metamodel for Modeling Interorganizational Business Processes==
https://ceur-ws.org/Vol-601/EOMAS10_paper4.pdf
Proposition of a Generic Metamodel for
Interorganizational Business Processes
Khoutir Bouchbout1, Jacky Akoka2, Zaia Alimazighi1
1: Computer Science Department, USTHB University, Algiers, Algeria
2: équipe ISID, Laboratoire CEDRIC/CNAM-Paris, Paris, France
kbouchbout@gmail.com, alimazighi@wissal.dz, jacky.akoka@cnam.fr
Abstract. An Interorganizational Business Process (IOBP) is an organized
group of related activities carried out by multiple organizations to accomplish a
common business goal. A consequence of this is that business process modeling
and design used inside an organization have to be enhanced and extended to
cope with interorganizational business relationships. Modeling business
processes that span multiple organizations involves new challenges, mainly the
ability to cope with autonomy, privacy, heterogeneity, and the support for
coordination trough mutual agreements. As a contribution to this area, this
paper presents a metamodel that captures a wide range of IOBP elements.
Keywords: Interorganizational business process, business process modeling,
interorganizational business process metamodel, MDA-based framework, B2B.
1 Introduction
Collaboration and coordination between companies are considered necessary in a
business environment, where companies focus on their competitive advantage,
perform only those functions for which they have expert skills and they complement
their offering through partners and suppliers. Interorganizational business processes
are the enabler of such business environments. The modeling of IOBP is a
challenging task, due to the high degree of autonomy and heterogeneity of the
cooperative organizations. The paper proposes an IOBP generic metamodel which
depicts the nature of interaction between organizations through business processes
under specific business requirements that emphasize the heterogeneity, privacy and
autonomy of the participating organizations.
For this purpose, we conducted explorative research which is considered
appropriate for gaining better insight and for analyzing particularities of
interorganizational processes in comparison with internal processes. Having answered
this question, metamodel elements should be derived that are considered necessary for
metamodeling IOBP.
The remainder of the paper is structured as follows. In section 2, we present basic
concepts of IOBP. Section 3 highlights the framework for IOBP design. In section 4,
we discuss the related works. Section 5 describes the aspects of the proposed IOBP
metamodel. Finally, the paper finishes giving a summary and an outlook to future
work.
J. Barjis, M.M. Narasipuram, G. Rabadi, J. Ralyté, and P. Plebani (Eds.):
CAiSE 2010 Workshop EOMAS’10, Hammamet, Tunisia, pp. 42-56, 2010.
Generic Metamodel for Modeling Interorganizational Business Processes 43
2 Interorganizational Business Processes Basic Concepts
A business process is a continuous series of organizational tasks, undertaken for
the purpose of creating output [25]. Among the forms of information that people
ordinarily want to extract from a process model are what is going to be done, who is
going to do it, when and where will it be done, how and why will it be done, and who
is dependent on its being done [7].
This section aims to present the basic definitions and concepts of IOBP modeling.
2.1 Intra-organizational versus Interorganizational Business Processes
While intra-organizational processes comprise activities executed inside one
organization only, the activities comprised in an IOBP are executed by different
organizations that are working together to reach a common objective. Hence, a
number of particularities arise in comparison with intra-organizational business
processes [12]. IOBP usually do not have a centralized control instance or process
owner. Coordination between the different organizations requires an agreement on
how to interact and exchange information. However, autonomy of the different parties
has to be taken into account when designing IOBP.
In order to illustrate the IOBP concepts, we regularly refer to the following
corporate procurement process example scenario depicted by the figure 1.
Application example: The Procurement application concerns two organizations
(enterprises) – a buyer and a seller – which are collaborating and need to interlace
their business processes. The Buyer sends an initial request for quote to the Seller.
The Seller checks if the requested product is offered, i.e. listed in its product
catalogue. If so, then the stock information is required in order to see if the product is
kept in stock. If the product is out of stock, product information is needed to check if
the product can be produced or not. In cases of either having the product in stock or
having to produce the product, the Seller needs to calculate its price and to send back
a quote to the Buyer. If the requested product is not offered by the Seller and cannot
be produced, a rejection is sent back to the Buyer. In case of having received a quote
for the requested product, the buyer checks if the price corresponds to the price limit
set; if so, it sends a PO to the Seller. The Seller then verifies the credibility of the
Buyer. If the credibility is ok, the Seller returns an order response to the Buyer.
Fig.1. An example of an IOBP
44 K. Bouchbout, J. Akoka and Z. Alimazighi
In order to make IOBP work, each involved organization has to implement not only
its internal processes (private processes), but also its external behavior (public
processes). Hence, in IOBP modelling it is common to distinguish between internal
and external activities of business processes. Adopting the approaches used by
([5],[16],[12],[19],[26],[33],[35],[36,[41]), we consider a process described either as a
Private (internal or executable), Public (abstract or view), and Collaborative (cross-
organizational or interorganizational) as illustrated in figure 1, figure 2, and figure 3.
• Collaborative Business Processes define the interactions (vertical dashed arrows in
figure 1) between two or more business companies. These interactions take place
between the defined public processes and are defined as a sequence of message and/or
other material input/output exchange as depicted in figure 2. The collaborations
between the involved parties are modeled as interaction patterns between their roles.
It is shown by two or more public processes communicating with each other.
Fig.2. An example of an IOBP: Collaborative & Public processes
• Public Process abstracts information from one or more private processes and thus
enables companies to hide critical information from unauthorized partners. It is an
interface to the outside world which extracts only that kind of information which is
necessary for interaction with one or more potential partners. A public process defines
an external message exchange of an organization with its partners according to a
message exchange protocol like PIPs (www.rosettanet.org). Thus a public process can
be seen as general interaction description of one or more private processes from the
perspective of one partner. Seller’s public activities are represented in grey and
Buyer’s public activities are represented in white in figure 2.
• Private Processes are internal to an organization. They contain data not to be
revealed by default (private activities are represented in grey and public activities are
represented in white in figure 3). On private process level, organizations model their
internal business processes according to a modeling approach that is most suitable for
internal demands independently of the modeling methodologies used by the business
partners [34]. For example a Seller wants to hide the “Check product catalog”, “Get
stock info”, “Get product info” ,“Calculate product price”, and “ Check customer
credibility” activities from Buyer.
Generic Metamodel for Modeling Interorganizational Business Processes 45
Fig.3. An example of an IOBP: Public vs. Private processes
To explain specifics of IOBP modeling, we will discuss the requirements and
particularities of interorganizational business processes.
2.2 Particularities of Interorganizational Business Processes
The approaches investigated until now introduce a representation of the
interorganizational business process, which uses either an existing modeling notation
or its extensions. Specific artifacts are necessary for describing interorganizational
business processes, among them external organizations, roles or partner types as well
as messages, business documents and channels. With regard to the allocation of tasks
to the actors in the interorganizational business process, partition concepts have
become popular.
Important contributions to handling the specifics of IOBP come from research on
workflow management, e.g. the Public-To-Private Approach ([1], [40]) and the View-
based Process Model ([11], [26], [27], [33], [35], [36]). Hence and based on a
literature review ([8],[19],[20],[22], [23],[41]), we deduce in the following the most
important specific particularities for IOBP modeling.
1. No central governance of the global process. There is no entity that designs,
implements, executes, and monitors the end-to-end process [24]. This requirement
follows the assumption that central governance reduces the autonomy of the parties
and may require visibility to details that are not necessarily visible in a purely
distributed process. Then the organizations can hide their processes from other
organizations. In interorganizational environments the internal business processes are
one key competence of the organizations they want to preserve from the other
organizations. In order to support these requirements, a flexible information hiding
mechanism is required.
2. Autonomy of business Partners. Each partner has a full autonomy to design,
implement, execute and monitor its internal processes, provided they comply with the
partner's obligations toward the other partners [23]. The IOBP participants act
autonomously and must coordinate themselves by means of interactions.
3. Generation of executable processes. The distributed execution of an IOBP starts
with a common process model that all partners share and that is business oriented.
46 K. Bouchbout, J. Akoka and Z. Alimazighi
From this model every partner extracts those parts that he has to execute and
augments them with arbitrary information he needs for execution [12]. Thus the used
modelling language should be able to transfer the IOBP from business level into an
IT-oriented workflow model on technical level like e.g. BPEL.
4. Support of organizational units and roles. Because different partners are
involved in an IOBP, it is important to describe the organizational units with the
communication and reporting relationships within the IOBP. Furthermore, the role
defines the requirements profile of an organizational unit, particularly necessary for
workflow applications. Thus, the modelling language should be able to describe the
different organizational units and roles of the partners within the IOBP [41].
5. Support of activity semantics. For interoperability reasons, trading partners have
to exchange electronic business documents. Since each partner has its own systems
and culture, they could use different terms and metadata structures to represent their
data, even when referring to the same domain of interest. Inefficiencies concerning
the electronic exchange of data and information can be eliminated by the definition of
central semantic and syntactic standards for exchange objects (for example business
documents) as well as transfer methods (transmission medium, exchange protocols
etc.) in order to achieve semantic interoperability [13].
2.3 Overview of the Current Business Process Modeling Languages
To specify IOBP, big efforts have been made during recent years and many
languages have been proposed. The origins of process modeling languages are quite
diverse (see Table 1). Today, there are a lot of conceptual business processes
modelling languages available. This section discusses the evaluation of four well-
known of them which are used generally in the intra-organizational case.
Table 1. Comparison of business processes modeling languages.
Petri Net EPC UML 2 AD BPMN 2
Issue Edition C. A. Petri, 1962 Keller, Nüttgens OMG, 2004 BPMI,
& Scheer, 1992 OMG, 2009
Perspective IT Perspective Business Object-Oriented IT/Business
perspective perspective perspective
Source domain Formal Business Software Business
specification engineering engineering engineering
Specification Academic Proprietary Open Open
Purpose Analysis, Description, Description, Description,
verification Analysis enactment enactment
Although there is an abundance of business process modeling languages, only a
few were applicable for IOBP modeling in practical cases. One major requirement of
business/IT specialists in practice is that business process modeling languages should
be widely used in industry and in commercial products. This is the case for EPC [32]
and UML [39]. UML is of additional importance because there is a strong
Generic Metamodel for Modeling Interorganizational Business Processes 47
organization (OMG [39]) behind UML pushing it. This is also the case for BPMN [4].
Another reason of importance is the ability of formal analysis, optimization and
verification, which is the case for high level Petri Nets [29]. Thus, in this section we
analyze and compare the modeling languages High Level Petri Nets, EPC (ARIS),
UML2 AD, and BPMN. An overview of the evaluation results can be found in Table
2. Our evaluation scale ranges from comprehensively fulfilled (depicted by +),
partially fulfilled (+/-) to not fulfilled (-).
Note that we selected those four languages among many others like IDEF3,
BPML, RAD, and DFD ([7],[8],[9],[24],[37]) because they either provide a set of
interesting concepts and/or are supported by a prominent industrial consortium.
Despite their diversity, all the different modeling approaches have their pros and
cons. However, the comparison presented in this section shows that no single
language fulfills all requirements identified for specifying IOBP.
Table 2. Comparison of business processes modeling languages (cont.).
Petri Net EPC UML 2 AD BPMN 2
Support of private, public, +/- +/- +/- +
IO Processes
Representation power +/- +/- +/- +
Support of analysis control + +/- - -
Interaction patterns + +/- +/- +/-
protocols
Semantic annotations - + +/- +
Support of involved role +/- + - +/-
Tool support notation +/- + +/- +
Mapping to exec. language + (BPEL) +/-(BPEL) +(BPEL) +(BPEL)
3 Framework for Interorganizational Business Process Design
To meet the IOBP particularities we have presented above, we propose a novel
approach for building an IOBP based on a Model-Driven Architecture (MDA) as
illustrated in figure 4. The framework is characterized by a set of
transformations/mappings (horizontal and vertical) at and across different layers.
The MDA is a framework for software development driven by the Object
Management Group (www.omg.org). The following three models are at the core of
the MDA: (1) Computation Independent Model (CIM): This is the most abstract
model within MDA independent of computational technology; (2) Platform
Independent Model (PIM): This model is defined at a high level of abstraction; it is
independent of any implementation technology. It describes a software system that
supports some business; (3) Platform Specific Model (PSM): A PIM is transformed
into a PSM for each specific technology platform. Processes at PIM level shall be
described in such a way, that they can be transformed to process execution languages
on PSM level.
48 K. Bouchbout, J. Akoka and Z. Alimazighi
We note that the term of metamodel is put in relation with the OMG’s MOF
(Meta Object Facilities) [28], which is an abstract framework, and a four-layered
architecture for defining and managing metamodels, neutral of any technology ([3],
[16] [18]). Metamodels are simply referred to as being just “models of models” [13].
While a model is an abstraction of phenomena in the real world, a metamodel is an
abstraction of the model itself. A Metamodel comprises an explicit description
(formalized specification) of constructs, rules and notation for building domain-
specific models.
Fig.4. MDA-based framework for IOBP design
The vertical dimension distinguishes the different layers of abstraction applied in
MDA and the horizontal dimension represents the collaborative modelling between
two enterprises A and B. Business process models of enterprise A and B have to be
shared at different level of abstraction in order to agree on and develop IOBP. The
gaps between these abstraction levels are overcome by vertical transformations like
presented in [19]. We assume that enterprise A and B use different business process
modelling tools and languages at the PIM/PSM MDA layers. To develop IOBP both
enterprises have to provide public parts of their models as basis for discussion for
collaborative modeling. The vertical transformation in the downward direction
corresponds to process automation approaches where conceptual models are
transformed to executable processes. Both enterprises have to exchange at least parts
of their models as a basis for collaborative modeling (UML 2 [39], ebXML [41]).
Hence, models of enterprise A (BPMN [4]) and B (EPC [32]) are shared at PIM layer.
4 Description and Evaluation of the Related Works
Before we present our approach for IOBP metamodeling we will briefly refer to
some related work in the following propositions done in the field of
Workflows/Business Process metamodels.
List et al. [22] developed a generic metamodel composed of 5 contexts. They are
inspired from the work of [7]. On a high level, this metamodel addresses the
following views: Business Process Context Perspective, Behavioral Perspective,
Generic Metamodel for Modeling Interorganizational Business Processes 49
Functional Perspective, Informational Perspective, and Organizational Perspective.
The functional perspective represents what process elements are being performed, and
what flows of informational entities, are relevant to these process elements. The
behavioral perspective basically describes the order in which the different activities
are executed. The organizational perspective describes the organization structure and,
in particular, the resources and in which way these are involved in the BP. The
informational perspective describes the information that is involved in a BP, how it is
represented, and how it is propagated among the different activities. The business
process context perspective captures important business process context information
like process goals and performance measures or process type. However, this
metamodel is not well adapted to represent interorganizational relationships.
In the proposition of Morley [25], the metamodel is based on two assumptions.
First, the underlying modelling approach is a top-down one. A Process is initially
defined by the Purpose assigned to it. It can be described at several levels of
granularity, but the last level is the only one to be detailed. This is particularly useful
when drawing cartography of all the enterprise business processes. Then, the notion
of Activity is a central concept, due to the influence of the standard process
definitions dedicated to enterprise modelling. The starting point is to model the
Activities and then to define the suitable organization with Roles and Actors.
However, this metamodel is not well adapted to represent interorganizational
relationships.
Kradolfer [17] develops a workflow metamodel that allows defining the
functional/structural, informational, behavioral, and organizational aspects of
workflows. The workflow metamodel is modular in the sense that the various
elements (workflows, organizational entities, etc.) can be specified independently of
each other, and in that no assumptions are made in which context the elements are
going to be used. For instance, activity assignment, control and data flow are not
specified with the activities themselves, but only when the activities are used within a
workflow. The metamodel is activity-centric in that it allows to “think” in terms of
activities/workflows and their results instead of states or transitions. However, this
metamodel lacks the representation of some IOBP elements (private and public
business processes).
Saidani and Nurcan ([30], [31]) provide a start points for the definition of a
methodology allowing the design of adaptive and flexible BP metamodels according
to the situation at hand. They have introduced the concepts of BPM-chunk and
business method. They promote the fact that the final business process model has to
be created from the set of proposed chunks in order to suit to a particular situation.
Their approach aims to make easier the definition of flexible and customized meta-
models. However, this metamodel do not consistently support interorganizational
model requirements and concepts.
5 The Proposed IOBP Generic Metamodel
There is a lot of work done on the definition of intra-organizational business
process metamodel ([2],[3],[5],[10],[12],[16],[17],[22],[25],[30],[34]), but it misses
some research clearly addressing the case of the interorganizational business process
50 K. Bouchbout, J. Akoka and Z. Alimazighi
metamodel. Relying in the approaches of these metamodels, we extend and adapt
them into one combined high level generic metamodel addressing all the requirements
of the IOBP seen before.
For this aim we structure our metamodel into four aspects according to the
metamodel developed by Curtis et al. [7]: functional, behavioral, organizational, and
informational. Besides the four business process aspects, there are further non-
functional requirements a business process metamodel should fulfill: enactability,
ease of use, correctness criteria, evolution, and reuse.
For readability reasons, we display the most important concepts in each of the
four aspects separately in a UML class diagram.
• Functional aspects: What has to be performed?
The functional aspects of the metamodel are shown in figure 5. The concept of
activity is one of the core concerns of every metamodel we studied. To enable an
exchange of process data using IOBP, information might be hidden via “private
process”, “public process”, and “collaborative process” process elements, which hide
critical private process data.
Events are things that “happen” during the course of a business process. There
exist three types of events: interrupt, temporal, and trigger. Examples of these events
include change in delivery date, change in price, etc.
Fig. 5. Functional & Behavioral aspects metamodel
The figure 6 depicts the application of the metamodel functional aspects to the
purchase order processing IOBP example seen before in the section 2.1.
Generic Metamodel for Modeling Interorganizational Business Processes 51
Fig. 6. Example of Functional & Behavioral aspects metamodel
• Behavioral aspects: How is produced? (Control flow, data flow,, rules)
The behavioral aspects of the metamodel are shown in figure 5 (analogue to [22]).
Specification of control flow is essential in IOBP for the coordination of business
process participants. Our metamodel supports the basic (sequence, branch) structures
in order to be programmatically complete. Activities and events are connected by
sequence flows indicating the order in which activities will be performed or events
occur in a business process. Conditional expressions and various split and join
restrictions are provided for advanced branching and synchronization patterns.
• Organizational aspects: Who does it? (Stakeholder, role, and organizational unit)
The organizational aspects of the metamodel are shown in figure 7. We can
distinguish two major categories of “process stakeholder”. In the first one the
stakeholder is concrete. It may be a person, a computer program, a department, a
position in the enterprise but it is an entity which exists apart from the process. In the
second category the stakeholder is abstract. It defines a role which is played in the
process and covers a set of properties (skills, capabilities, degree of responsibility …)
which may be expected from the concrete stakeholder which will be assigned to this
role. Hence, the modelling of IOBP requires an additional role model different to the
internal role model. It should allow specifying the role of the organization as a whole
in a public business process. A “collaboration role” defines the observable behavior
that a party exhibits when collaborating with other parties in the public process.
52 K. Bouchbout, J. Akoka and Z. Alimazighi
Fig. 7. Organizational aspects metamodel
The figure 8 depicts the application of the metamodel organizational aspects to the
purchase order processing IOBP example seen before in the section 2.1.
Fig. 8. Example of organizational aspects metamodel
• Informational aspects: What is produced/exchanged? (physical resource, business
document, service, software application, information object)
The informational aspects of the metamodel are shown in figure 9. There may be
lot of things behind the resource concept. On one hand resource artifacts are
considered to be pieces of information. On the other hand they are concrete products
like material, service or information. The resource may be of different nature
according to the nature of the field covered by the metamodel. Some focuses on
software process and others on manufacturing or service supplying processes.
Fig. 9. Informational aspects metamodel
Generic Metamodel for Modeling Interorganizational Business Processes 53
In other words, informational aspects represent elements describing information,
material or other artefacts that are objects used by the process activities, e.g. Business
documents, material that is to be sent, money that is to be received, etc. This is
inspired by the workflow data patterns as well as by the input/output view of ARIS
[22]. Specification of data flow must additionally consider autonomy and privacy of
organizations.
The figure 10 depicts the application of the metamodel informational aspects to
the purchase order processing IOBP example seen before in the section 2.1.
Fig. 10. Example of Informational aspects metamodel
6 Conclusion and Future Research
The increasing interest in process engineering and application integration has
resulted in the appearance of various intensive works related to business process
metamodeling both in academia and in the industry. The importance of IOBP has
been widely recognized, leading to a variety of approaches and proposed solutions to
their design and implementation. To describe and analyze existing approaches to
model business processes we first described requirements distinct for
interorganizational scenarios. For the representation of the IOBP elements the
approaches of the intra-organizational business process modeling languages like EPC,
BPMN, and UML 2 AD were adapted and extended because they do not address
conveniently the particularities of the interorganizational business process. So, we
developed an IOBP independent generic metamodel common to these languages
which ensures the best suitability to model IOBP.
Modelling IOBP requires specific constructs and methodologies, and requires a
high-level model and the corresponding executable one for exchanging and merging
behaviors, resources and activities. Our current research activities focus on employing
the MDA approach such that, based on a platform independent model of an IOBP, it
is possible to automatically derive business process specifications expressed in the
specification languages best suited for any of the different activities.
54 K. Bouchbout, J. Akoka and Z. Alimazighi
The developed generic IOBP metamodel provides the capability to represent and
model business processes independent of notation or methodology, thus bringing
these different approaches together into a cohesive capability.
As further work, we will validate the metamodel by instantiating it with a case
study example in order to verify the completeness of the proposed concepts, then
completed it with the necessary transformations to the involved business process
models (EPC, UML2 AD, and BPMN) according to the MDA approach.
Acknowledgment
The work published in this paper was achieved within the ISID research team of
CEDRIC/CNAM-Paris, France that the authors want to thank all members for their
valuable help.
References
1. Aalst Van der W.M.P. and Weske M.: The P2P approach to Interorganizational
Workflows. In K.R. Dittrich, A. Geppert, and M.C. Norrie, editors, Proceedings of
CAiSE'01, LNCS Vol. 2068, 140--156. Springer-Verlag, Berlin, (2001).
2. Akoka J., Lang D.: Places de marché électroniques et reconfiguration des processus
interorganisationnels, Actes du 7ème colloque de l’Association Information &
Management, Hammamet, Tunisie, (2002).
3. Breton Erwan, Bézivin Jean: An Overview of Industrial Process Meta-Models,
ICSSEA’2000, 14 December 2000, Paris, France, (2000).
4. BPMN Business Process Modeling Notation specification: OMG Final Adopted
Specification, OMG, February 2006, URL:
http://www.bpmn.org/OMGFinalAdoptedBPMNl-0Spec2006-02-01.pdf, (2006)
5. Chebbi Issam, Dustdar Schahram, Tata Samir: The view-based approach to dynamic inter-
organizational workflow cooperation, Data & Knowledge Engineering, Vol. 56, 139--173
(2006).
6. Chiu D. K. W., Karlapalem K., Li Q., and Kafeza E.: Workflow View Based E-Contracts
in a Cross-Organizational E-Services Environment, Distributed and Parallel Databases,
vol. 12, pp. 193--216, (2002).
7. Curtis Bill, Kellner Marc I. and Over Jim: Process Modeling, Communications of ACM,
Vol. 35(9), (1992).
8. Dorn J., Grün C., Werthner H., and Zapletal M.: A Survey of B2B Methodologies and
Technologies: From Business Models towards Deployment Artifacts. Proceedings
HICSS’07, (2007).
9. Freiheit, J.; Matheis, T., Ziemann, J.: Definition of static and dynamic models of
collaborative workflow interoperability. Deliverable D4.1, R4eGov – Towards e-
Administration in the large. Proceedings IST’2004, (2004).
10. Ghannouchi Sonia Ayachi, Jamel Menzli Leila: Proposition et expérimentation d’un
métamodèle pour la réingénierie des processus métier, Ingénierie des Systèmes
d’Informations, Vol. 13(3), 105--129(2008).
11. Grefen Paul, Ludwig Heiko, and Angelov Samuil: A three-level framework for process
and data management of complex e-services, International Journal of Cooperative
Information Systems, Vol. 12, No. 4, 487--531 (2003).
Generic Metamodel for Modeling Interorganizational Business Processes 55
12. Greiner, U., Lippe, S., Kahl, T., Ziemann, J., Jäkel, F.W.: Designing and implementing
cross-organizational business processes - description and application of a modelling
frame-work. In Proceedings I-ESA’2006, (2006).
13. Höfferer, Peter: Achieving business process model interoperability using metamodels and
ontologies, Proceedings ECIS’2007, (2007).
14. Huemer C., Liegl P., Schuster R., Werthner H., and Zapletal M.: Inter-organizational
Systems: From Business Values over Business Processes to Deployment. Proceedings
DEST’2008, (2008).
15. Koehler, J., Hauser, R., Kapoor, S., Wu, F.Y. & Kumaran, S.: A Model-Driven
Transformation Method, Proceedings EDOC’2003, p. 186, (2003).
16. Korherr Birgit, List Beate: Extending the EPC and the BPMN with Business Process
Goals and Performance Measures. 9th International Conference on Enterprise Information
Systems (ICEIS07), Portugal, ACM Press, (2007).
17. Kradolfer Markus: A workflow metamodel supporting dynamic reuse-based model
evolution, PhD thesis, University of Zurich, Switzerland, (2000).
18. Lazarte Ivanna M., Chiotti Omar and Villarreal Pablo D.: Transforming Collaborative
Process Models into Interface Process Models by Applying an MDA Approach, AIS
Transactions on Enterprise Systems, Vol. 2, 13--23(2009).
19. Legner Christine, Vogel Tobias, Löhe Jan, Mayerl Christian: Transforming Inter-
Organizational Business Processes into Service-Oriented Architectures. Method and
Application, Proceedings of KiVS 2007, Bern, Switzerland, (2008).
20. Legner Christine, Wende Kristin: The Challenges Of Inter-Organizational Business
Process Design – A Research Agenda, University of Saint Gallen, Switzerland,n (2007).
21. Lin, F-R., Yang M-C., and Pai, Y-H.: A generic structure for business process modeling,
Business Process Management Journal, Vol. 8 No. 1, 19--41, (2002).
22. List Beate, Korherr Birgit: An Evaluation of Conceptual Business Process Modelling
Languages, Proceedings of the 2006 ACM Symposium on Applied Computing (SAC’06),
Dijon, France, ACM Press, (2006).
23. Medjahed, B., Benatallah, B., Bouguettaya, A., Elmagarmid, A.: Business-to-business
interactions issues. The VLDB Journal, Vol. 12, 59--85, (2003).
24. Mendling, J., Nüttgens, M. and Neumann, G.: A Comparison of XML Interchange
Formats for Business Process Modelling. In F. Feltz, A. Oberweis and B., Proceedings of
EMISA 2004, LNI 56, 129--140, (2004).
25. Morley Chantal : Un cadre unificateur pour la représentation des processus, Pre-ICIS.
Cahiers de recherche, INT Management, Ivry, France, (2005).
26. Norta Alexis, Grefen Paul: Discovering Patterns for Inter-Organizational Business
Collaboration; International Journal of Cooperative Information Systems; Vol. 16, No.
3/4, 507—544 (2007).
27. Nurcan Selmin, Etien Anne, Kaabi Rim, Zoukar Iyad, and Rolland Colette: A strategy
driven business process modelling approach. Business Process Management Journal,
11(6), 628--649 (2005).
28. OMG: Meta Object Facility (MOF) Core Specification. Version 2.0 (2006).
29. Petri, C.A.: Kommunikation mit Automaten. Dissertation, Technische Universität
Darmstadt. Institut für Instrumentelle Mathematik, (1962).
30. Saidani Oumaima, Nurcan Selmin: Towards Situational Business Process Meta-
Modelling, Proceedings of CAISE’08, 93-96 (2008).
31. Saidani Oumaima, Nurcan Selmin: A Role-based approach for modeling flexible business
processes, Proceedings of CAISE/BPMDS’06, (2006).
32. Scheer, A.-W.; ARIS Business Process Modeling. Springer Verlag, (1999).
33. Schulz K. A. and Orlowska M. E.: Architectual Issues for Cross-Organisational B2B
Interactions, in 21st International Conference on Distributed Computing Systems
Workshops (ICDCSW '01), pp. 79--87, (2001).
56 K. Bouchbout, J. Akoka and Z. Alimazighi
34. Seel Christian, Vanderhaeghen Dominik: Meta-Model based Extensions of the EPC for
Inter-Organisational Process Modelling, Proceedings "EPK 2005", Hamburg, Germany,
(2005).
35. Shan Z., Chiu D.K.W., Li Q.: Systematic Interaction Management in a Workflow View
Based Business-to-business Process Engine, Proceedings HICSS’2005, (2005).
36. Shen, M., & Liu, D.R.: Coordinating interorganizational workflows based on process-
views. Proceedings of the 12th International Conference on Database and Expert Systems
Applications, 274-283, (2001).
37. Söderström E, Andersson B, Johannesson P, Perjons E, Wangler B.: Towards a
Framework for Comparing Process Languages. Proc. of the 14th International Conference
on Advanced Information Systems Engineering; pp. 600--611 (2002)
38. Strahonja Vjeran: The Evaluation Criteria of Workflow Metamodels, Proceedings of the
ITI 2007 29th Int. Conf. on Information Technology Interfaces, June 25-28, 2007, Cavtat,
Croatia, (2007).
39. Unified Modeling Language Specification, Object Management Group (OMG), version
.2.0. http://www.omg.org.
40. Wombacher, A.; Aberer, K.: Requirements for Workflow Modeling in P2P-Workflows
derived from Collaboration Establishment; in Proc. 1st Intl. Workshop on Business
Process Integration and Management (BPIM 04), Zaragoza, Spain, IEEE Computer
Society Press, 1036--1041 (2004).
41. Ziemann Jorg, Matheis Thomas, Freiheit Jorn: Modelling of Cross-Organizational
Business Processes - Current Methods and Standards, Proceedings EMISA’2007, LNI,
Vol.119, 87--100 (2007).