1
Achieving Enterprise Model Interoperability Applying
a Common Enterprise Metamodel
Jörg Ziemann1, Oddrun Ohren
2, Frank-Walter Jaekel
3, Timo Kahl
1, and Thomas
Knothe3
1 Institute for Information Systems (IWi), Saarbrücken, Germany
{ziemann, kahl}@iwi.uni-sb.de
2 SINTEF, Oslo, Norway
3 Fraunhofer IPK, Berlin, Germany
{frank-walter.jaekel, thomas.knothe}@ipk.fraunhofer.de
1 Introduction
As response to changes in competitive conditions in many industries [1],
enterprises specialize in specific core competencies, and rely on the outsourcing of
less relevant business activities [2]. This increases the demand for close inter-
organizational collaboration and makes the collaborative activities themselves
more complex. Interoperability - defined as “ability of two or more systems or
components to exchange information and to use the information that has been
exchanged” [3] is a prerequisite for successfully implementing collaborative
business. For enterprises which are documenting the different dimensions of their
business (e.g. processes, organizational structures, decisions) with the help of
enterprise models, the ability of a mutual understanding of semantic and syntax of
these models over organizational borders is necessary for obtaining
interoperability. This paper illustrates an ATHENA approach to foster inter-
company model exchange, by transforming them into a generic metamodel. The
metamodel consists of different dimensions (process, product, organisation,
infrastructure and decision) in order to enable companies to exchange the full range
of models. For illustrating purposes this paper focuses on transformation between
the process dimensions of the EML. The concept and its implementation will be
exemplified by transformation between Event-Driven Process Chains (EPC) and
Integrated Enterprise Modelling (IEM) format. EPC [4] enable business analysts
to model processes on a non-technical level and are frequently used to represent
business requirements, e.g. in the context of SAP with the SAP Reference Model
2 Book Title
[5]. IEM [6] supports the understanding across the different stakeholders of
enterprise processes within and across organisations. In difference to most studies
available on transformation between business process modelling languages (e.g.
[7]), the presented transformation approach is based on the experiences gained by
various tool vendors and applied in practical use cases. Additionally, the described
transformation between EPC and IEM was verified by two prototypes for im- and
exporting process models from EPC to IEM respectively IEM to EPC. After an
introduction in the process dimension of the POP* metamodel (“Process,
Organisation, Product and others*”) [8], the conceptual mapping of EPC and IEM
is described and a example transformation is provided, illustrating mapping options
and possibilities of metamodel driven transformation. Finally, section 4 provides a
summary and an outlook on future research.
2 Representing Processes in the POP* Metamodel
The main objective of the POP* methodology is to provide a “standard” model
exchange device, a common format containing a set of basic modelling constructs.
By creating mappings from individual enterprise modelling languages (EMLs) to
this common format, enterprises will be able to exchange models in those EMLs.
In other words, POP* aims to support interoperability between enterprises that use
different modelling languages. The exchange device mentioned is the POP*
methodology, and consists of the POP* metamodel together with guidelines and
scenarios for its management and use. A XML format for POP* called EKA [9]
and a platform called Modelling Platform for Collaborative Enterprises (MPCE)
[10] supplement the methodology. The work is inspired by already existing
initiatives and standards, most notably the process oriented BPDM [11], BPMN
[12], UEML 1.0 [13] and ISO/DIS19440 [14]. Although some overlap may be
found between POP* and the mentioned initiatives, the ambition for ATHENA is
for POP* to take a holistic approach, covering all relevant aspects of collaborating
enterprises.
Intuitively, an enterprise is very complex, and is correspondingly hard to
capture in a model in its entirety. The ATHENA approach is to decompose the
concept of enterprise into several dimensions, each representing a certain aspect of
an enterprise, or a perspective from which to consider the enterprise in question.
The approach of such dimensions is used in other approaches, too, e.g. are ARIS,
which contains Data, Control, Output, Organization and function view or IEM
incorporating product, resource and control as well as class and process view. The
challenge is to achieve common concepts to exchange the information expressed in
this different approaches. Corresponding to the perceived view on dimensions of
an enterprise, the POP* meta-model is organised according to knowledge
dimensions. The dimensions define conceptual domains of the metamodel, each
with their own set of constructs to be used for modelling the enterprise. Presently,
five dimensions are included in POP*, namely the Process, Organisation, Product,
Decision and Infrastructure dimensions, in addition to a set of general concepts
(POP* Core) applicable by all dimensions. Nonetheless, as the meaning of * in
Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel 3
POP* indicates, the standard is open for dimensions to be added in future. The
current dimensions are described as follows:
1. The Organisation dimension focuses on organisational structures, human
beings and their interaction.
2. The Process dimension includes constructs related to activities, tasks and
processes going on in the enterprise or between enterprises.
3. The Product dimension is used to model product architectures or product
structures.
4. The Decision dimension is used to model the decision-making structure in
terms of decision centres and decision activities.
5. The Infrastructure dimension includes constructs to support modelling of
infrastructures and the services they provide.
The process dimension includes modelling constructs related to activities, tasks
and processes going on in an enterprise or between enterprises (cp. Fig. 1). The
basic elements in a POP* compliant process model are connect points connected
by flows. Any connect point may have zero or more flows coming in to or going
out from it, and the logical behaviour in each case is denoted by its properties in-
flow logic and out-flow logic, respectively.
Fig. 1. The process dimension metamodel
A connect point may be either a process or a gateway. The decomposable
concept of Process is used to represent any kind of activity or work, at any level of
abstraction. Gateways has the same (flow) logical capabilities as Process, but is
4 Book Title
empty in the sense that it does not represent any work, and is used mainly to
represent forks and joins in the process flow.
Various types of resources and actors may be connected to the process by any
of the relationships has input, has output, has control and has resource, indicating
the resources’ and actors’ participation in the process. Note that the relationships
mentioned relates objects directly to the process in which they take part. Their
respective parts in the process are expressed by attaching roles to the relationships.
In this context roles may be one of the subtypes Input, Output, Control or
Resource, which are to be attached to the has input, has output, has control and has
resource relationships, respectively. Fig. 2 illustrates this by an excerpt from the
transformation between EPC and IEM via POP* as described in chapter 3.
Fig. 2. Connecting resources to a process
A process called “Evaluate Message” has an object called “Message” as input.
This is represented by the has input relationship between “Evaluate Message” and
“Message”. To make explicit the role of the message as input to the process, a role
of type Input, called “Basis_for_Evaluation”, is attached to the has input relation.
The interpretation of this is that “Message” fills the “Basis_For_Evaluation” role
when “Evaluate Message” is performed. As indicated above, flows relate connect
points to each other, and as such specify the process logic. Flows may carry any
kind of object (e.g. material, information, money, manpower, etc) from one
connect point to the next, expressed by using the relationship carries between Flow
and an object. Moreover, process roles may be attached to the flow, and if so, the
assumed interpretation is that the carried object is to fill the attached roles at
execution time. POP* also facilitates another way of connecting information to
flows, namely by allowing states to be attached to a flow. Typically, states
connected to flows represent key information needed to choose between separate
paths of the process.
3 Transformation between POP* Metamodel and EML
For the mapping and transformation of metamodel elements, the correponding
transformation rules might consist of different parts: the description of single
elements, of model fragments consisting of various elements (e.g. patterns) and
transformation logic [15]. The latter expresses computations and constraints on
model elements and can be described as relationships between model elements in
an executable form, which can take a declarative or an imperative form. This
article focuses on metamodel elements and their relationships; nonetheless, the
Evaluate Message [ Process ]
[ Connect Point ] [ Outflow Logic XOR]
Message [EKA Object ]
Basis_For_Evaluation [Input Role ]
Has Input [ Relationship ]
Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel 5
prototypes implemented contain imperative rules in form of Java code. Four
possible mismatches while mapping elements of an ontology to grammatical
constructs can be identified [16]: Deficiency of modelling constructs, excess of
modelling constructs, overloading of constructs and redundancy of constructs.
These mismatches might also occur in mappings between elements of a specific
EML to the elements of a generic enterprise metamodel, e.g. POP*.
Correspondingly, mappings between the metamodels may be uni- or bidirectional.
In case of the redundancy and the overloading relationship, bidirectional mappings
are possible, though in case of redundancy a decision has to be made to which of
two possible target elements a source element has to be mapped. In case of excess
only unidirectional transformations are possible, because in the other direction the
case of deficiency occurs, which hinders the transformation of some metamodel
elements. These relationships apply to modelling languages as well as single
elements of a language. For example, the elements of the EPC metamodel might
have the relationship of redundancy to the elements of the POP* metamodel if one
element of EPC can be mapped to various constructs of POP*. In some cases two
elements have to be mapped despite of differences. For example, the mapping
between the EPC process to the POP* process is obvious, though both have
different characteristics (cp. section 3). Fig. 3 shows the models whose mappings
are described in this article and their representations in XML.
EPC model in ARIS Toolset POP * model IEM in MO2GO
AML model EKA-XML model IEM XML model
Fig. 3. Model exchange between ARIS Toolset and MO²GO go via POP*
3.1 Transformation between EPC and POP*
The EPC is established since more then a decade for the purpose of semi-formal
business process modelling. It represents business processes by sequences of
events and functions put in logical and timely order. A function represents a value-
adding part of the business process, an event is a passive component of the process,
representing states of a system respectively operational conditions that may
influence further execution of the business process. To model the control flow,
vectored links as well as conjunctive (AND), disjunctive (XOR) and adjunctive
(OR) connectors are used. Various EPC elements exist to further describe
characteristics of the functions, i.e. the organizational unit responsible for
execution of the function can be attached to it. Fig. 4 illustrates an example process
modelled in EPC which will be transformed into the IEM language. It describes
how a message is received, evaluated (by the “Management” department) and
responded to.
In the following, the mapping between elementary EPC elements and POP*
elements is described. An EPC function realizes a predefined business objective by
transforming input to output data. A function has decision competence regarding
following controll flow elements and can be divided recursively in smaller
functions. The corresponding element in POP* is called process. Through the is
part of relationship a POP* process can be divided in sub processes, too. Processes
6 Book Title
can be put in sequence with other processes by means of flows and decision points.
Thus, the syntactical characteristics (decomposability, connection through flows)
of EPC function and POP* process are similar. Semantically, the definition of the
POP* process, not describing its characteristics as strictly as the definition of the
EPC function, is broader.
ENDMessage
received
Evaluate
Message
Manage-
ment
XOR
Message
approved
Message
rejected
Send
„approved“
Send
„rejected“
XOR
Fig. 4. Example Process in EPC-Notation
An EPC event is a predefined state of an information system determining the
execution of following process activities. Events trigger functions, are triggered by
functions, can specify business conditions and can reference on data objects. In an
EPC sequence, events and functions are always alternating, though logical
operators may follow both elements. Currently in the process dimension POP* no
direct equivalent to the EPC event exists, only the state element attached to the
POP* flow. But since the EPC event can be seen as a specialization of state, it is
matched to this POP* element. The position of the POP* state being attached to
the flow allows displaying EPC sequences containing events embedded by
functions or by functions and connectors. Thus, semantically the state in POP* is
broader than the EPC function. EPCs contain AND, XOR and OR splits as well as
join connectors to determine the logic of the process control flow. Though these
operators are alone standing elements, in case they represent a decision (e.g. XOR
or OR-split) they have to follow a function which is responsible of the decision. In
cases of AND-split, AND-join, OR-join and XOR-join the connectors can either
follow a function, an event or another operator. In POP* these kind of splits and
joins appear either in an alone standing element (gateway) or they are embedded in
a process. In both cases the elements can have various incoming and/or outgoing
links. Incoming and outgoing links are related by the OR, XOR or AND logical
relationship. In case of OR/XOR splits, the decision which link to take can be
based on the states attached to the flows. For example one flow leaving a gateway
representing an XOR-Split could represent the state “Message approved” while the
state on the other flow represented the “Message rejected” state. Thus the EPC
connectors can be represented in POP*. Transformation of POP connect points in
form of gateways as well as embedded in processes to EPC logical connectors is
also possible (in the last case the POP* process would be mapped to an EPC
function and an EPC connector). An EPC process represents a self contained
sequence of enterprise activities with the objective of producing goods or services.
Syntactically, it is a sequence of events, functions and connectors. A POP* process
is defined more broadly as used to represent processes, tasks and activities of any
kind. While in the EPC function and event elements are alternating, in POP* the
sequence of states and processes does not have to be alternating, e.g. the sequence
Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel 7
Process AProcess BEvent C is allowed. But this sequence does not comply
with the syntax of EPCs, thus, if no workaround are used, transformation from
EPC to POP* processes is unidirectional. Adding so called trivial events to the
target model allows for such a workaround: For each POP* process that is not
followed by a state, an EPC event is generated stating the end of the previous
function.
3.2 Transformation between IEM and POP*
To provide for comprehensive and expandable enterprise models, the IEM
(Integrated Enterprise Modelling) method within the MO²GO System [17] uses the
object-oriented modelling approach, allowing the integration of different views on
an enterprise in one consistent model and the easy adaptation of the model to
changes within the enterprise. The generic classes ‘Product’, ‘Resource’, Order’ as
well as the class ‘Action’ for process representation are the foundations of the IEM
method for developing models from a user’s point of view. IEM “Product”
represents the results of the entire enterprise process. IEM “Resource” represents
all means, including organizational units and IT systems, which are necessary to
carry out any activity in the enterprise. IEM “Order” represents planning and
control information. The generic classes can be further specialised to the targets of
an individual modelling project e.g. an organisation unit as a subclass of the IEM
“Resource” class. Each element of the IEM model can contain attributes defined
within the class schemas. A sample model expressing the descriptions covered by
the EPC example of the previous section is illustrated in Fig. 5.
Fig. 5. IEM process chain example
Required enterprise data and corresponding enterprise business processes are
structured in accordance with the object classes. Furthermore, the relations
between objects are determined. The result is a comprehensive description of tasks,
business processes, enterprise data, etc. of the enterprise at any level of detail.
Actions together with product, resources and order states are combined to
represent business processes. In POP* the Action is represented as Process and the
IEM States as POP* States. The connection elements (‘Split’, ‘Join’, ‘Decision’)
are expressed in POP* by Gateway. The connection elements as well as Gateways
can contain further information about their logic (e.g. or, and, synchronised, etc.).
The decomposition and aggregation of processes is supported on the action
8 Book Title
element similar to the POP* process element. A detailed process is represented by
a bold border around the action element. Further modelling aspects related to
special modelling purposes can be integrated as additional views on the model.
States can have multiple graphical representations within one modelling level and
across different levels. Table 1 illustrates the mapping between the IEM process
modelling elements, POP* and EPC on a generic level. Further mappings taking
into account extended modelling concepts such as “organisation unit”, “human
resource”, “finance” which might be required for a richer interface to EPC can be
modelled in IEM/MO²GO with extensions of the class structures and exchanged by
addressing the related dimensions and types in POP*.
Table 1. Mapping between EPC, POP* and IEM/MO²GO
EPC/ARIS POP* IEM/MO²GO
Process Process Action
Function Process Action
Event State Product State [Input, Output]
Event State Order State [Input, Output]
Event State Resource State [Input, Output]
Organisational Unit Object from the dimension
“organisation”
State of resource object from
class “Organisation”
Control Flow Flow between connect points Flow Connector
Join
[AND, OR, XOR]
Gateway -In-flow-logic=
[AND, OR, XOR]
Join:Logic=
[AND, OR, XOR]
Split
[AND, OR, XOR]
Gateway -Out-flow-logic=
[AND, OR, XOR]
Decision:Logic
[AND, OR, XOR]
Edge with “has-
resource” attribute
has-resource (Process has-
resource State)
Resource: Conditional
Connector
A difference between POP* and MO²GO is the ability of POP* processes to
have more than one connector between modelling elements. In order to map
correctly this constructs one to another, the import/export mechanism includes
recognizing of these patterns and creating of additional Joins on import as well as
omitting unnecessary ones on export (POP* rule). Since in POP* Flows can exist
only between processes (or corresponding Inputs or Outputs, but not States), the
typical MO²GO construct of Actions interconnected with connectors over states is
mapped to a single Flow, which has the link to a State as a Member.
3.3 POP* Based Transformation between EPC and IEM
The scope of POP* is sufficiently extensive to cover elements of both languages
and table 1 exemplified that the main elements of the control flow could be
Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel 9
matched between EPC and IEM. It also illustrates that possible deficiencies arise,
e.g. overloading: Different IEM state types might be mapped to the same POP*
state and therefore to the same event. These points are under consideration in the
further activities especially the use of possible semantic support.
4 Summary and Future Research
This article presented a transformation approach enabling companies to exchange
enterprise models across EMLs using the POP* metamodel and illustrated the
approach by transformation between EPC and IEM. Mappings between EML and
POP* were given and an example illustrated how, despite syntactical and
semantical heterogeneously constructs in EPC and IEM, the POP* metamodel can
be applied for automatic transformation between the languages. As a proof of
concept, the transformation between POP* and IEM as well as between POP* and
EPC was implemented in two Java tools which rely on the corresponding XML
notations (e.g. IEM-XML, EKA-XML and the ARIS Markup Language) and use
the Document Object Model (DOM) for their modification.
One challenge for future research is related to the graphical representation of
the models. Since diagram tools do not have unified coordinate systems and
representation strategy the utilization of the graphical information exported by
other tools is limited. Next development steps of POP* will include heuristics for
improving the layout of imported models. In transforming the EML to a generic
metamodel further tool specific features have to be preserved, e.g. the distinction
of the ARIS Toolset between a synchronized copy of a function and an instance
copy of a function. And, paying tribute to the need for exact description of
metamodel elements, in future semantically typed elements in POP* as well as the
EML could provide for easier creation of mappings between the elements.
The impact of POP* depends on its attractiveness for tool vendors (e.g. easy
adoptability) as well as its standardisation. Apart from the EML described here, in
ATHENA mappings for POP* were developed for two other EML. The POP*
concept is now an annex of ISO 19440 which is under final balloting. It is also sent
to OMG as input to the ongoing work on BPMN and BMM.
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. We want to thank Mr.
Marcus Bitterlich and Mr. Stanimir Dragiev for assisting us implementing the
transformation tools.
References
[1] Scheer, A.-W., Werth, D., Kahl, T., Martin, G.: Lösungen für das Unternehmen von
morgen - Next Generation Business. In: IM - Fachzeitschrift für Information
Management & Consulting. imc AG, Saarbrücken (2004)
[2] Naisbitt, J.: Megatrends: Ten New Directions Transforming Our Lives. Warner
Books, New York (1986)
10 Book Title
[3] IEEE Standard Computer Dictionary – A Compilation of IEEE Standard Computer
Glossary, New York (1990)
[4] Keller, G., Nüttgens, M., Scheer, A.W.: Semantische Prozessmodellierung auf der
Grundlage Ereignisgesteuerter Prozessketten (EPK). Technical Report 89. Institut
für Wirtschaftsinformatik, Saarbrücken (1992)
[5] Keller, G., Teufel, T.: SAP(R) R/3 Process Oriented Implementation: Iterative
Process Prototyping. Addison-Wesley (1998)
[6] Spur, G., Mertins, K., Jochem, R.: Integrated Enterprise Modelling, Beuth, Berlin
Wien Zürich (1996)
[7] Ziemann, J., Mendling, J.: EPC-Based Modelling of BPEL Processes: a Pragmatic
Transformation Approach. In Proceedings of the 7th International Conference Modern
Information Technology in the Innovation Processes of the Industrial Enterprises
(MITIP 2005). Genova (2005)
[8] Ohren, O. P., Chen, D., Grangel, R., Jaekel, F.- W., Karlsen, D., Knothe, T., and
Rolfsen, R. K.: ATHENA-A1, Deliverable DA1.5.2: Report on Methodology
description and guidelines definition. In: ATHENA A1 deliverables. SINTEF, Oslo
(2005)
[9] Jorgensen, H.D., Karlsen, D., Lillehagen, F., Smith-Meyer, H., Solheim, H.G.: The
ATHENA Enterprise Knowledge Architecture – Utilizing Mutually Reflective Meta-
Views to Enable Business Interoperability. In CE2005: The 12th ISPE International
Conference on Concurrent Engineering: Research and Applications Next Generation
Concurrent Engineering. Omnipress Madison (2005)
[10] Solheim, H.G., Jorgensen, H.D., Karlsen, D., Lillehagen, F., and Smith-Meyer, H.:
Obliterating the border – Concurrent modeling and execution platform. In: CE2005:
The 12th ISPE International Conference on Concurrent Engineering: Research and
Applications Next Generation Concurrent Engineering. Omnipress Madison (2005)
[11] Object Management Group: Business Process Definition Metamodel (2004)
[12] Object Managment Group: BPMI.org, in: Business Process Modeling Notation
(BPMN). Version 1. (2004)
[13] Berio, G. et al.: Deliverable D 3.1, Requirements analysis: initial core constructs and
architecture. (UEML v. 1.0). In: Thematic network - IST-2001-34229. Torino (2003)
[14] International Organization for Standardization: Enterprise integration - Constructs for
enterprise modelling (ISO/DIS 19440). Prepared by CEN TC 310 and ISO/TC 184.
ISO, Geneva (2004)
[15] Czarnecki, K., Helsen, S.: Classification of Model Transformation Approaches. In:
Bettin, J., Boas, G. v. E., Agrawal, A., Willink, E. und Bezivin, J. (eds.)., Proceedings
of the 2nd OOPSLA workshop on Generative Techniques in the Context of Model-
driven Architecture. ACM Press (2003)
[16] Wand, Y., Weber, R.: On the Ontological expressiveness of Information Systems
Analysis and Design Grammar. In: Journal of Information Systems, Vol. 3, No. 2.
(1993)
[17] Mertins, K., Jaekel, F.-W. MO²GO: User Oriented Enterprise Models for
Organizational and IT Solutions. In: Bernus, P., Mertins, K., Schmidt, G.: Handbook
on Architectures of In-formation Systems. Second Edition. Springer-Verlag, Berlin
Heidelberg (2006)
Recommended
