1 Achieving Enterprise Model Interoperability ... - Semantic Scholar

1 Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel Jörg Ziemann1, Oddrun Ohren2, Frank-Walter Jaekel3, Timo Kahl1, and Thomas Knothe3 1

Institute for Information Systems (IWi), Saarbrücken, Germany {ziemann, kahl}@iwi.uni-sb.de 2

SINTEF, Oslo, Norway [email protected] 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 interorganizational 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 intercompany 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 inflow 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. Basis_For_Evaluation [Input Role ]

Evaluate Message [Process ] [Connect Point ] [Outflow Logic XOR]

Has Input [ Relationship ]

Message [EKA Object ]

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


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 valueadding 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. Management Message received

Evaluate Message

Message approved

Send „approved“

XOR

XOR Message rejected

END

Send „rejected“

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


Process AProcess BEvent 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

Gateway -In-flow-logic=

Join:Logic=

[AND, OR, XOR]

[AND, OR, XOR]

[AND, OR, XOR]

Split

Gateway -Out-flow-logic= [AND, OR, XOR]

Decision:Logic

has-resource (Process hasresource State)

Resource: Conditional Connector

[AND, OR, XOR] Edge with “hasresource” attribute

[AND, OR, XOR]

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


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]

[2]

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) 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) 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) Keller, G., Teufel, T.: SAP(R) R/3 Process Oriented Implementation: Iterative Process Prototyping. Addison-Wesley (1998) Spur, G., Mertins, K., Jochem, R.: Integrated Enterprise Modelling, Beuth, Berlin Wien Zürich (1996) 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) 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) Jorgensen, H.D., Karlsen, D., Lillehagen, F., Smith-Meyer, H., Solheim, H.G.: The ATHENA Enterprise Knowledge Architecture – Utilizing Mutually Reflective MetaViews to Enable Business Interoperability. In CE2005: The 12th ISPE International Conference on Concurrent Engineering: Research and Applications Next Generation Concurrent Engineering. Omnipress Madison (2005) 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) Object Management Group: Business Process Definition Metamodel (2004) Object Managment Group: BPMI.org, in: Business Process Modeling Notation (BPMN). Version 1. (2004) 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) 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) 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 Modeldriven Architecture. ACM Press (2003) 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) 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)

[4]

[5] [6] [7]

[8]

[9]

[10]

[11] [12] [13] [14]

[15]

[16]

[17]