A Multi-level Modeling Framework for Designing and
Implementing Cross-Organizational Business Processes
Ulrike Greiner
1
, Sonia Lippe
1
, Timo Kahl
2
, Jörg Ziemann
2
, Frank-Walter Jäkel
3
1
SAP Research, Karlsruhe (Germany) / Brisbane (Australia)
2
DFKI, Saarbrücken (Germany)
3
FhG IPK, Berlin (Germany)
Abstract. Increasing cooperation of organizations leads to the necessity of
efficient modeling and implementation of cross-organizational business
processes (CBPs). Various stakeholders that pursue different perspectives on
processes are involved in the design of CBPs. Enterprise modeling supports a
common understanding of business processes for different stakeholders across
organizations and serves as basis to generate executable models. Models
include knowledge of internal processes as well as demands for CBPs. The
paper presents concepts and a first prototype of a modeling framework
supporting process designers to get a common agreement on their processes
across different companies on different levels of abstraction.
1 Introduction
Increasing cooperation between organizations is a global trend. Independent
organizational units or entire organizations build temporary or permanent
collaborations, which pool resources, capabilities, and information to achieve a
common objective [1]. New business models are emerging and existing procedures
are redesigned forming long running processes between various (external) partners –
so called Cross-Organizational Business Processes (CBPs).
The successful implementation of CBPs requires a common agreement between all
stakeholders involved (“process owners”) and a clear understanding of the common
processes. Ideally modeling of CBPs is supported by a modeling framework that starts
from enterprise models identifying business structures and interrelations between
organizations on business level. To come from business level models to executable
processes, detailed execution oriented modeling and evaluation have to be performed
on a platform independent technical level. To support re-use of process models and
enable enterprises to keep up with the constant change in business relationships well-
defined (and possibly largely automated) model transformations between the business
level and the technical level should be provided.
This paper presents such a framework to model interoperable business processes.
Furthermore practical experiences made with the application of the framework in the
furniture industry are presented. The paper focuses on the first two levels whilst
details in the execution level are not considered. It is the intension to close the gap
Greiner U., Lippe S., Kahl T., Ziemann J. and J
¨
akel F. (2006).
A Multi-level Modeling Framework for Designing and Implementing Cross-Organizational Business Processes.
In Proceedings of the 1st International Workshop on Technologies for Collaborative Business Process Management, pages 13-23
Copyright
c
SciTePress
currently existing between processes defined on a business level and executed models
(Fig. 2).
First characteristics and requirements that have been formulated in [2] and have to be
addressed in a modeling framework for CBPs are verified based on the analysis of a
collaboration scenario (Section 2). The framework developed within the ATHENA
research project (http://www.athena-ip.org) is presented in Section 3. We then sketch
a prototypical implementation of the two dimensions of the framework. The focus
within this work is on control-flow as a fist implementation goal. In section 4.1 a
concept is shown how to hide sensitive information in collaborative scenarios on a
business level whereas section 4.2 targets the transformation from a business to a
technical level as a first step for the execution of CBPs.
Fig. 1. Furniture eProcurement Scenario.
2 Scenario Analysis
The scenario describes the interaction between a furniture manufacturer, a retailer and
a supplier. In the following we concentrate on the quotation and order part of the
scenario. Fig. 1 gives an overview of the interactions between the three partners.
The scenario consists of two parts, the retailer-manufacturer collaboration and the
manufacturer-supplier collaboration. The retailer-manufacturer process starts when
the retailer prepares a Request for Quotation (RfQ) for a decoration project. This RfQ
is sent through the Internet to the manufacturer’s sales department. The Sales
Department takes care of RfQ processing and contacts other departments, such as
product design or administration, in order to complete the quotation to be sent back to
the retailer. The retailer accepts the quotation and sends back an order for requested
products. The process of the manufacturer contains two sensitive sub processes: the
checking of the solvency of the retailer and the calculation of a price discount. If the
retailer orders more than 10 products a month 10% discount is given, in all other
cases the retailer gets no discount. This process has to be distributed to several
retailers in order to show them the sequence of the order processing so that they can
inform their staff and configure their workflow engines. The manufacturer wants to
hide his discount system from certain customers; the solvency check should be hidden
always.
During order processing (creating Bill of Material and Production) the manufacturer
has to order material in case the warehouse is under stocked. This triggers the
manufacturer-supplier collaboration (left part of the figure). The procurement
department prepares and sends an RfQ to the appropriate supplier .The supplier
14
calculates the production cost of the requested material and responds with a formal
quotation including the expected amount and a forecasted delivery date. Once the
manufacturer has received back the order from the supplier, it is processed and an
order confirmation is sent to its retailer.
A detailed analysis of modeling and implementing the scenario at the respective
partners revealed the following challenges:
- It is necessary to provide a level of abstraction on which the partners first agree
on the business goals of their collaboration. To implement the collaboration with
ICT systems the involvement of technical staff is necessary. Thus a successful
modeling framework should support different graphical modeling languages
meeting the needs of all involved stakeholders. To avoid re-modeling and to
facilitate an execution of the processes defined on business level transformation
concepts between the levels should be offered.
- The internal business processes of each partner have to be linked into a CBP
without revealing private information. The extent to which information contained
in internal processes is exposed to business partners should be easily adaptable. For
instance, the manufacturer might provide a long known retailer with information
about his private process that has be hidden from a new retailer. E.g. the process
description for the new retailer might not reveal internal discount politics.
- Simplified process adoption has to be achieved. E.g. a supplier interacting with
different manufacturers should not require different private processes for each
collaboration it is involved in.
- Depending on the level of trust between the collaborating partners, a scalable
exposition of internal processes should be possible.
These requirements have already been identified in [2] on a more detailed level. The
framework presented in the following section addresses these requirements as well as
the requirements identified in the case study.
Related Work. Different modeling frameworks have previously been defined for
business process or enterprise modeling. These include the ‘Framework for
Information Systems Architecture’ (Zachman Framework) [3] and the ‘Architecture
of Integrated Information Systems’ (ARIS) [4]. Both frameworks offer modeling
support from different user perspectives. The ARIS architecture distinguishes
between organization, function, output, information and control views. The purpose
of the Zachman Framework is to provide a basic structure which supports
organization, access, integration, interpretation, development, and management of a
set of architectural representations of the organizations’ information systems.
Although both frameworks combine different user perspectives and allow modeling
on different levels of abstraction, the focus of these frameworks is on internal process
modeling. They lack methods which allow modeling of cross-organizational
collaborations as a creation of an external view on the organization (as required for
CBPs) is not supported.
The UN/CEFACT Modeling Methodology (UMM) is specifically designed to provide
a modeling procedure for specifying CBPs, in a technology neutral, implementation
independent manner [5]. However, there is no notion of process abstraction and no
support for linking up internal processes to CBPs without revealing confidential
information.
15
3 A Framework for the Design and Implementation of CBPs
The framework consists of two dimensions:
1. Modeling levels between design and execution of the CBP, and
2. Aggregation and filtering of information trough additional abstraction layer.
The first dimension of the modeling framework deals with the requirement of
different modeling users and stakeholders involved in the business process. These
levels are similar to the different types of models used in model-driven architectures
[6]. However, as the focus is specifically on modeling cross-organizational business
processes, different names are chosen for the three levels to distinguish the more MDI
related approach as described in [7] from the general approach of model-driven
architectures:
Business level: This level represents the business view on the cooperation and
describes the interaction of the partners. The CBPs modeled on this level allow for
analyzing business aspects, like costs, involved resources etc.
Technical level: This level provides a more detailed view on the CBP representing the
complete control flow of the process. Non-executable tasks are not regarded. Also the
message exchange between single tasks is modeled on this level and can be analyzed.
However, the control flow and the message exchange are specified in a platform
independent manner. This supports reuse of the process models as the models on this
level can be ported to various means of execution.
Execution level: On this level the CBP is modeled in the modeling language of a
concrete business process engine. It is extended with platform specific interaction
information, e.g., the concrete message formats sent or received during CBP
execution or the specification of particular data sources providing data during process
execution.
The second dimension is based on the introduction of process views as an additional
abstraction layer between the private processes and the CBP model as proposed by
Schulz [8], [9]. Process views provide a process-oriented interface towards business
partners. Private processes are only known to their owning organization and not
exposed to the outside world. Process views are an abstraction of the private
processes, containing information that needs to be published for the purpose of a
specific interaction. Several tasks of a private process can be combined to one view
task. A similar approach is proposed by Weske, Aalst called P2P approach (public to
private) [10]. However, this approach only allows for an outside-in modeling where
the internal process is defined based on an inheritance principle from the public
process. It is the goal of the modeling framework proposed within this paper to
support an outside-in, inside-out and mixed approach as required in a specific
modeling context.
This leads to the following definitions in the proposed framework:
Cross-Organizational Business Processes (CBP): A CBP defines the interactions
between two or more business entities. These interactions take place between two or
more companies defined as valid sequences of message and/or other material
input/output exchanges.
Private Processes (PP): PPs refer to a specific organization and are the type of
processes that have been generally called workflow processes.
View Process (VP): A VP combines one ore more PP to an abstract level that enables
companies to hide critical information from unauthorized partners.
16
The framework structure incorporates (Fig. 2):
- Different user groups and modelers are involved in modeling cross-organizational
business processes.
- The selectively hiding of internal process steps while offering a mechanism to
expose CBP relevant information to partners.
At each intersection between the two framework dimensions, a possible process
model can be identified to capture tasks and relationships of cross-organizational
interactions. Thus, it is ensured that all relevant perspectives on CBP models as well
as the processes required for the view concept are properly captured and modeled.
Models can be distinguished between mandatory and optional models for the CBP
implementation (Fig.2). On business level it is compulsory for all involved parties to
create a view model, specifying the externally visible business context for a specific
CBP scenario. This can be used for partner communication on management or
business analyst level. Also required is a CBP model which specifies from a high
level business perspective how the partner processes are interweaved.
Fig. 2. Modeling Framework.
The inter-enterprise coordination builds on a distributed business process model
where partners manage their own part of the overall business process. A CBP
specifies tasks that each of the parties is required to perform as agreed in their
contract (specified in terms of business level models). Although the CBP model will
not be executed and therefore does not exist on execution level [9], it is required for
the specification of the message exchange on the technical level. It can be used for
monitoring purposes in the actual enactment phase. A process view can be considered
as a proxy for its corresponding private process. In other words, a process view is
outsourcing its implementation to its corresponding private process [9]. Therefore it is
mandatory that both models are specified on the technical level. The framework
allows creating various views on the same internal processes when interacting in a
different context. It is the intent that a process modeler can leave a private process
unchanged and create a special view process which can be adapted to satisfy specific
business requirements.
17
4 Application of the Modeling Framework
The implemented prototype of the modeling framework includes the following
modeling languages and tools (Fig. 3):
- On the business level the ARIS Toolset [4] and MO²GO [11]. The two modeling
tools are chosen to illustrate the capability to follow the CBP concept in different
tools and methodologies. ARIS supports EPC (Event-driven Process Chain) [12]
and MO²GO supports the Integrated Enterprise Modeling (IEM) [13], [14].
Common representations as well as differences are identified but finally both tools
are able to transfer the required data to the technical level via PIM4SOA [15].
- On the technical level Maestro [16].
- On the execution level BPEL4WS [17].
Fig. 3. Modeling tools and languages in framework prototype.
In this paper we will illustrate the abstraction of information on a business level
(horizontal dimension of the framework) based on an EPC-example whereas the
vertical dimension of the framework will be exemplified by the transformation from
IEM to PIM4SOA [15] (transformation from a business to a technical level).
4.1 Modeling CBPs on a Business Level with ARIS
In order to enrich an EPC with functionalities required to model CBPs, new
constructs have been implemented. In order to abstract from sensitive process
information, the EPC is extended by the object type process module. This construct
depicts a closed logical unit that reflects a reasonable and clearly limited part of a
business process. A process module can substitute a single function as well as a sub-
process. To supplement correlation between view and private process models, each
view process has a unique ID. A similar mechanism is defined as process type for
IEM.
An example for using process modules is shown in Fig. 4. In this figure the private
process of the furniture manufacturer’s order processing is on the left side. As
described in section 2, the process contains an area to check the solvency and an area
to calculate a possible discount for the retailer. Thus the manufacturer creates two
18
different views of the same internal process for two classes of retailers by subsuming
the area labeled as “abstraction area 1” and “abstraction area 2” into process modules.
Apart from creating views of private processes in a collaborative scenario, it is also
necessary to define the business scenario on a high level of abstraction. Therefore, a
new model is proposed that enables business experts to specify the scenario in an
abstract manner while hiding sensitive process information. The model aims at
adapting and optimizing the complete collaboration, therefore all organizations
involved are displayed. It gives an overview of all view processes that are part of the
CBP including the organizational units that are in charge of these process steps. On
this level of abstraction it is not easy to organize the interaction between the
participants. The reason is the lack of information concerning the internal procedure
within the linked process modules.
Fig. 4. Private Process of Manufacturer and derived View Processes for Retailers.
One way of dealing with this problem is describing the required input as well as the
produced output of the view processes. In the overall concept this is expressed by the
input/output states in IEM or objects in eEPC. The direction of the connection shows
19
whether the object for the view process is input or output. The specification regarding
time, amount and quality gives an example about possible attributes that have been
taken into account. An example is given in Fig. 5.
Further details of the concepts and its realization with IEM can be found in
Deliverable A2.2 [18] of the ATHENA project.
Fig. 5. CBP – Overall View.
4.2 From Business Level to Technical Level: AN IEM to PIM4SOA
Transformation
The business level models created within MO²GO or the ARIS Toolset are
transformed to the technical level using PIM4SOA models [15] as an intermediate
format. In particular the view processes are transformed. In the following it is
described how the transformation from process models on the business level to the
technical level can be achieved using MO²GO. For the ARIS Toolset the
transformation concept is described in the deliverable D.A2.4 [19].
The MO²GO tool is extended to export models to PIM4SOA using XMI 2.0 interface.
The basis for this export is the conceptual mapping: IEM to PIM4SOA. Depending on
the complexity of the mapping the following different mapping levels are defined:
1. Generic Mapping: The “generic mapping” is a one to one mapping of IEM meta-
model constructs to PIM4SOA constructs. This mapping can easily be applied to
any IEM model but maybe not the whole relevant PIM4SOA content of the model
will be transformed into PIM4SOA format.
2. Extended Mapping: The term “extended mapping” is used to indicate a mapping
based on an extension of the generic IEM constructs by a specific PIM4SOA class
structure (meta-model). This allows defining and identifying more PIM4SOA
relevant content within IEM models. Using the specific PIM4SOA –IEM
metamodel the mapping is a one to one mapping and similar to the “generic
mapping”.
3. Structure Mapping: The term “structure mapping” is used to indicate that some
information can only be mapped to PIM4SOA by model fragments. This mapping
is complex and close to a graph pattern matching.
Related to the complexity of the different mappings the “generic mapping” and the
“extended mapping” can be done automatically. The “structure mapping” is under
consideration for “simple” patterns. Complex topologies have to be mapped,
manually. Thus, the transformation of some complex PIM4SOA patterns of several
elements can only be achieved by mapping patterns of several elements from IEM as
a whole. An example is given in Fig. 6.
20
A Ok
Timeout
B
C
A Ok
Timeout
B
C
Fig. 6. Structure Mapping.
In the Example Action A is performed. After it has finished a decision is made to
check if the Action finished due to a timeout (Order from Exception class) or it was
“Ok”. The corresponding PIM4SOA pattern might be only created if this IEM pattern
is mapped as a whole. When performing a mapping on this level the information for
all the elements connected to the element currently being mapped has to be checked
for pattern matching. In the example when trying to map Action A all of the elements
up to B and C have to be checked because they all match the PIM4SOA specific
pattern. It may also require significant effort to manually prepare an existing IEM
model for this level of mapping in case the model was not created using exactly the
same predefined IEM patterns. This increases the complexity of the structured
mapping and makes it a resource-consuming process. An extension to a semi-
automated approach is subject of further research. The IEM-PIM4SOA metamodel
consists of classes and attributes corresponding to the classes defined in the
PIM4SOA specification (see Fig. 7).
Fig. 7. Extension of IEM Action, Order, Resource by PIM4SOA concepts.
21
For example any instance of the subclass of the ServiceProvider class in MO²GO will
be exported as a PIM4SOA ServiceProvider element. Additionally, the processes in
MO²GO can be annotated to indicate executable, non-executable processes or
processes requiring user interactions. This information is used to transform only
execution relevant processes. On the technical level the process models are then
imported via XMI into the Maestro tool.
On the technical level the view processes are linked to existing technical private
processes to realize the information hiding principle and are also connected to the
final CBP. In this step also the message exchange between the view processes is
specified. Maestro supports the creation of the CBP with a graphical modeling
interface and guided procedure that leads the user through the necessary design steps.
Maestro also generates all technical information describing the linkage between
private processes and view processes that is then relevant for the process execution.
During technical level modeling the user also specifies the services that are called
during runtime to execute the different steps in the view processes and private
processes of the partners. This information is necessary to generate executable
business process models.
5 Summary and Future Research
Interoperability requires a consolidated and consistent understanding across all
stakeholders. To ensure a correct cooperation between two or more entities it is
mandatory to build an appropriate process model. This can lead to a stronger
amplification of all the cross-interface activities and constraints between the entities.
We presented a modeling framework to support efficient design and implementation
of CBPs. Business level models, e.g. enterprise models, illustrate the organizational
business aspects as a prerequisite for the successful technical integration of IT
systems or their configurations. The technical model derived from the business level
model secures the technical realization of the process interaction and represents the
bridge to the process execution. Further work will address the realization of the (semi-
)automated transformation from the technical to the execution level and the
application in further business scenarios. Apart from BPEL4WS other standards for
Web Service based execution of CBPs will be considered, e.g. the Web Service
Choreography Description Language (WS-CDL) [20].
Acknowledgements
The work published in this paper is (partly) funded by the E.C. through the ATHENA
IP. It does not represent the view of E.C. or the ATHENA consortium, and authors are
solely responsible for the paper's content.
22
References
1. Sydow, J.(1993). Strategische Netzwerke – Evolution und Organisation. 2. Nachdruck.
Wiesbaden, Gabler
2. Lippe, S., Greiner, U., Barros, A.(2005). A Survey on State-of-the-Art to Facilitate
Modelling of Cross-Organisational Business Processes. In Proc. of XML4BPM 2005,
Karlsruhe
3. Zachman, J.A.(1987). A Framework for Information Systems Architecture. IBM Systems
Journal 26, No. 3, pp. 276-292
4. Scheer A.-W.(1999). ARIS – Business Process Modeling, 2nd. ed. Berlin
5. UN/CEFACT Modeling Methodology User Guide. Available at
http://www.ifs.univie.ac.at/untmg/artifacts/UMM_User_Guide_2003-09-22.pdf
6. OMG: Model Driven Architecture. Available at http://www.omg.org/mda/
7. Elvesater, B., Hahn, A., Berre, A., Neple, T.(2006). Towards an Interoperability
Framework for the Model-Driven Development of Software Systems. In Konstantas, D.,
Bourrieres, J.-P., Leonard, M., Boudjlida, N.(ed). Interoperability of Enterprise Software
and Applications. (INEROP-ESA'05)). London, Springer Verlag Limited, pp. 409-420
8. Schulz, K.(2002). Modelling and Architecting of Cross-Organisational Workflows. PhD
thesis, The School of Information Technology and Electrical Engineering, The University
of Queensland, Australia
9. Schulz, KA., Orlowska, ME.(2004). Facilitating cross-organisational workflows with a
workflow view approach. Data & Knowledge Engineering 51(1), pp. 109-147
10. Aalst, v der W.; Weske, M. (2001). The (P2P) Approach to Interorganisational Workflows.
In Proc. Of the 13th annual Conference on Advanced Information Systems Engineering
(CAiSE01)
11. Mertins, K., Jaekel, F-W.(2006). MO²GO: User Oriented Enterprise Models for
Organizational and IT Solutions. In Bernus, P., Mertins, K., Schmidt, G.(ed.). Handbook on
Architectures of Information Systems. Second Edition. Heidelberg , Springer-Verlag, pp.
649-663
12. Klein, R.; Kupsch, F.; Scheer, A.-W. (2004). Modellierung inter-organisationaler Prozesse
mit Ereignisgesteuerten Prozessketten. In Scheer, A.-W. (ed.): Veröffentlichungen des
Instituts für Wirtschaftsinformatik, Nr. 178, Saarbrücken : Universität des Saarlandes
13. Spur, G., Mertins, K., Jochem, R.(1996). Integrated Enterprise Modelling, Berlin Wien
Zürich, Beuth
14. Mertins, K., Jochem, R.(1999). Quality-Oriented Design of Business Processes. Boston,
Kluwer Academic Publishers
15. ATHENA Consortium (2005a). PIM4SOA. http://www.athena-ip.org
16. SAP Research(2005). Maestro for BPM. Deliverable of the ATHENA project,
http://www.athena-ip.org
17. Andrews, T. et al. (2003) Business Process Execution Language for Web Services, Version
1.1
18. ATHENA Consortium D.A2.2.(2005b): Specification of a Cross-Organisational Business
Process Model – D.A2.2. ATHENA, Integrated Project - Contract n°:IST-507849,
http://www.athena-ip.org
19. ATHENA Consortium D.A2.4.(2005c): Architecture for Enactment and Integration of
Cross-Organizational Business Processes – D.A2.4. ATHENA, Integrated Project -
Contract n°:IST-507849, http://www.athena-ip.org
20. Kavantzas, N., Burdett, D., Ritzinger, G. (2004): Web Services Choreography Description
Language Version 1.0 - W3C Working Draft 27 April 2004,
Http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/
23