GI-Edition Gesellschaft für Informatik e.V. (GI) publishes this series in order to make available to a broad public recent findings in informatics (i.e. computer science and information systems), to document conferences that are organized in cooperation with GI and to publish the annual GI Award dissertation. The volumes are published in German or English. Information: http://www.gi.de/service/publikationen/lni/ Markus Nüttgens, Oliver Thomas, Barbara Weber (Eds.) M. Nüttgens, O.Thomas, B. Weber (Eds.): EMISA 2011 Broken down into • seminars • proceedings • dissertations • thematics current topics are dealt with from the vantage point of research and development, teaching and further training in theory and practice. The Editorial Committee uses an intensive review process in order to ensure high quality contributions. Lecture Notes in Informatics Enterprise Modelling and Information Systems Architectures (EMISA 2011) Hamburg, Germany September 22–23, 2011 ISSN 1617-5468 ISBN 978-88579-284-0 This volume contains the proceedings of the 4th International Workshop on Enterprise Modelling and Information Systems Architectures (EMISA 2011) which is jointly organized by the GI Special Interest Group on Modelling Business Information Systems (GI-SIG MoBIS) and the GI Special Interest Group on Design Methods for Information Systems (GI-SIG EMISA). It features a selection of 12 full papers and 12 research-inprogress papers from academia and practice on Information Systems, Business Informatics and Computer Science. Leading authors from academia and industry present state-of-the-art developments, experiences, and best practices in this volume. 3018001 GI P_190 Cover.indd 1 190 Proceedings 24.08.11 15:45 Markus Nüttgens, Oliver Thomas, Barbara Weber (Eds.) Enterprise Modelling and Information Systems Architectures (EMISA 2011) Hamburg, Germany September 22-23, 2011 Gesellschaft für Informatik e.V. (GI) Lecture Notes in Informatics (LNI) - Proceedings Series of the Gesellschaft für Informatik (GI) Volume P-190 ISBN 978-3-88579-284-0 ISSN 1617-5468 Volume Editors Prof. Dr. Markus Nüttgens Universität Hamburg 22765 Hamburg, Germany Email: markus@nuettgens.de Prof. Dr. Oliver Thomas Universität Osnabrück 49074 Osnabrück, Germany Email: oliver.thomas@uni-osnabrueck.de Assoc. Prof. Dr. Barbara Weber Universität Innsbruck 6020 Innsbruck, Austria Email: barbara.weber@uibk.ac.at Series Editorial Board Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt, Austria (Chairman, mayr@ifit.uni-klu.ac.at) Hinrich Bonin, Leuphana Universität Lüneburg, Germany Dieter Fellner, Technische Universität Darmstadt, Germany Ulrich Flegel, Hochschule Offenburg, Germany Ulrich Frank, Universität Duisburg-Essen, Germany Johann-Christoph Freytag, Humboldt-Universität zu Berlin, Germany Thomas Roth-Berghofer, DFKI, Germany Michael Goedicke, Universität Duisburg-Essen, Germany Ralf Hofestädt, Universität Bielefeld, Germany Michael Koch, Universität der Bundeswehr München, Germany Axel Lehmann, Universität der Bundeswehr München, Germany Ernst W. Mayr, Technische Universität München, Germany Sigrid Schubert, Universität Siegen, Germany Martin Warnke, Leuphana Universität Lüneburg, Germany Dissertations Steffen Hölldobler, Technische Universität Dresden, Germany Seminars Reinhard Wilhelm, Universität des Saarlandes, Germany Thematics Andreas Oberweis, Karlsruher Institut für Technologie (KIT), Germany ! Gesellschaft für Informatik, Bonn 2011 printed by Köllen Druck+Verlag GmbH, Bonn Preface The strategic importance of modelling is recognised by an increasing number of companies and public agencies. Enterprise modelling delivers the ‘blueprints’ for co-designing organizations and their information systems, such that they complement each other in an optimal way. Achieving this interplay requires a multi-perspective approach that takes into account technical, organizational and economic aspects. It also recommends the cooperation of researchers from different fields such as Information Systems, Business Informatics and Computer Science. The 4th International Workshop on Enterprise Modelling and Information Systems Architectures (EMISA 2011) addresses all aspects relevant for enterprise modelling as well as for designing enterprise architectures in general and information systems architectures in particular. It is jointly organized by the GI Special Interest Group on Modelling Business Information Systems (GI-SIG MoBIS) and the GI Special Interest Group on Design Methods for Information Systems (GI-SIG EMISA). These proceedings feature a selection of 24 papers from academia and practice on enterprise modelling, enterprise architectures, business process management and measurements, analysis and explorative studies. We received 39 submissions which were thoroughly reviewed by at least three experts of the program committee. Twelve contributions were selected as full papers for presentation at the workshop and for publication in these proceedings. Additional, twelve papers were accepted as research-in-progress papers. We would like to thank the members of the program committee and the reviewers for their efforts in selecting the papers and helping us to compile a highquality program. We would also like to thank the local organization, in particular Nadine Blinn, Niels Müller-Wickop and Martin Schultz as well as Michael Fellmann and Novica Zarvic for their assistance with organizing EMISA 2011. We also thank Deborah Bunker and Ulrich Frank as keynote speakers. We hope you will find the papers in these proceedings interesting and stimulating. August 2011 Markus Nüttgens, Oliver Thomas, and Barbara Weber Program Co-Chairs Markus Nüttgens, University of Hamburg Oliver Thomas, University of Osnabrück Barbara Weber, University of Innsbruck Program Committee Witold Abramowicz, Poznan University of Economics Antonia Albani, University of St. Gallen Thomas Allweyer, FH Kaiserslautern Colin Atkinson, University of Mannheim Lars Bækgaard, Aarhus University Jörg Becker, University of Münster Khalid Benali, Nancy University Martin Bertram, Commerzbank Frankfurt Patrick Delfmann, University of Münster Jörg Desel, FU Hagen Werner Esswein, TU Dresden Fernand Feltz, Centre de Recherche Public-Gabriel Lippmann Luxembourg Ulrich Frank, University of Duisburg-Essen Andreas Gadatsch, Hochschule Bonn-Rhein Sieg Norbert Gronau, University of Potsdam Wilhelm Hasselbring, University of Kiel Heinrich Jasper, Freiberg University of Technology Reinhard Jung, University of St. Gallen Dimitris Karagiannis, University of Vienna Stefan Klink, University of Karlsruhe Ralf Klischewski, German University Kairo Horst Kremers, CODATA-Germany John Krogstie, University of Trondheim Susanne Leist, University of Regensburg Peter Loos, Universität des Saarlandes Heinrich C. Mayer, University of Klagenfurt Jan Mendling, Humboldt-University Berlin Mirjam Minor, University of Trier Bernd Müller, FH Wolfenbüttel Bela Mutschler, Hochschule Ravensburg-Weingarten Volker Nissen, TU Ilmenau Andreas Oberweis, University of Karlsruhe Sven Overhage, University of Augsburg Hansjürgen Paul, Institut Arbeit und Technik Erik Proper, Henri Tudor, Luxembourg and Radboud Univ. Nijmegen Michael Rebstock, University of Applied Sciences Darmstadt Manfred Reichert, Universität Ulm Stefanie Rinderle-Ma, University of Vienna Peter Rittgen, University of Borås Michael Rosemann, Queensland University of Technology Matti Rossi, Aalto University School of Economics Frank Rump, Fachhochschule Emden/Leer Gunter Saake, University of Magdeburg Eike Schallehn, University of Magdeburg Carlo Simon, Provadis Hochschule Marten van Sinderen, University of Twente Elmar J. Sinz, University of Bamberg Susanne Strahringer, TU Dresden Stefan Strecker, University of Duisburg-Essen Klaus Turowski, University of Augsburg Gottfried Vossen, University of Münster Hans Weigand, Tilburg University Mathias Weske, HPI Potsdam Robert Winter, University of St. Gallen External Reviewers Camlon Asuncion Nadine Blinn Marc Buergi Hans-Georg Fill Sandro Georgi Sandra Hintringer Patrick Hitzelberger Florian Johannsen Azeem Lodhi Benedikt Martens Gunnar Martin Syed Saif Ur Rahman Sebastian Schlauderer Boris Shishkov Niksa Visic Novica Zarvic Gregor Zellner Local Organisation Nadine Blinn, University of Hamburg Niels Müller-Wickop, University of Hamburg Martin Schultz, University of Hamburg GI-SIG MoBIS: Conceptual Modelling is pivotal for analysing and designing information systems that are in line with a company's long term strategy and that efficiently support its core business processes. The Special Interest Group on Modelling Business Information Systems (SIG MoBIS) within the German Informatics Society (GI) is aimed at providing a forum for exchanging ideas and solutions on modelling research within Information Systems - both for researchers at universities and experts in industry. GI-SIG EMISA: The GI Special Interest Group on Design Methods for Information Systems provides a forum for researchers from various disciplines who develop and apply methods to support the analysis and design of information systems. Contents Full Papers Beate Hartmann Enterprise Architecture as an Instrument of Strategic Control ............................ 9 Stephan Aier, Sabine Buckl, Bettina Gleichauf, Florian Matthes, Christian Schweda, Robert Winter Towards a More Integrated EA Planning: Linking Transformation Planning with Evolutionary Change .................................................................. 23 Agnes Nakakawa, Patrick Van Bommel, Erik Proper Applying Soft Systems Methodology in Enterprise Architecture Creation Workshops........................................................................................... 37 Stefanie Rinderle-Ma, Juergen Mangler Integration of Process Constraints from Heterogeneous Sources in Process-Aware Information Systems............................................................. 51 Robin Bergenthum, Jörg Desel, Sebastian Mauser Workflow Nets with Roles................................................................................. 65 Hanns-Alexander Dietrich, Matthias Steinhorst, Jörg Becker, Patrick Delfmann Fast Pattern Matching in Conceptual Models – Evaluating and Extending a Generic Approach.......................................................................... 79 Ulrich Frank Some Guidelines for the Conception of Domain-Specific Modelling Languages......................................................................................... 93 Bernd Michelberger, Bela Mutschler, Manfred Reichert Towards Process-oriented Information Logistics: Why Quality Dimensions of Process Information Matter ..................................................... 107 Niels Mueller-Wickop, Martin Schultz, Nick Gehrke, Markus Nüttgens Towards Automated Financial Process Auditing: Aggregation and Visualization of Process Models ............................................................... 121 Fabian Christ, Benjamin Nagel A Reference Architecture for Semantic Content Management Systems ............................................................................................................ 135 Mohammed Abujarour, Ahmed Awad Enriched Service Descriptions Using Business Process Configurations ......... 149 Jonas Repschläger, Stefan Wind, Rüdiger Zarnekow, Klaus Turowski Developing a Cloud Provider Selection Model ............................................... 163 Research-in-Progress Papers Stefan Zugal, Jakob Pinggera, Barbara Weber Assessing Process Models with Cognitive Psychology................................... 177 Frank Hogrebe, Nick Gehrke, Markus Nüttgens Eye Tracking Experiments in Business Process Modeling: Agenda Setting and Proof of Concept.............................................................. 183 Kathrin Figl, Barbara Weber Creative Personality and Business Process Redesign ...................................... 189 Matthias Wester-Ebbinghaus, Daniel Moldt Abstractions in Actor and Activity Modeling.................................................. 195 Sebastian Herwig, !ukasz Lis, Matthias Steinhorst, Jörg Becker, Patrick Delfmann A Generic Multi-purpose Conceptual Model Analysis Approach – Conceptual Specification and Application....................................................... 201 André Pflüger, Wolfgang Golubski, Stefan Queins System Architecture Validation with UML ..................................................... 207 Robert Heinrich, Alexander Kappe, Barbara Paech Tool Support for the Comprehensive Modeling of Quality Information within Business Process Models.................................................. 213 Matthias Boehm, Carl Stolze, Oliver Thomas Understanding IT-Management and IT-Consulting Teaching as Product Service System: Application of an Engineering Model ..................... 219 Oliver Kopp, Frank Leymann, Sebastian Wagner Modeling Choreographies: BPMN 2.0 versus BPEL-based Approaches........ 225 Michael Fellmann, Oliver Thomas Process Model Verification with SemQuu....................................................... 231 Benedikt Martens, Novica Zarvic, Frank Teuteberg, Oliver Thomas Designing a Risk-based Partner Selection Process for Collaborative Cloud Computing Environments ..................................................................... 237 Andreas Zolnowski, Martin Semmann, Tilo Böhmann Introducing a Co-Creation Perspective to Service Business Models............... 243 Enterprise Architecture as an Instrument of Strategic Control Beate Hartmann Department of Information Systems – Systems Engineering University of Bamberg Feldkirchenstr. 21 96045 Bamberg beate.hartmann@uni-bamberg.de Abstract: Enterprises compete in high dynamic and fast changing markets. Reacting quickly and flexibly to market changes is a crucial competitive advantage for an enterprise. Therefor premises of strategic planning and achievement of strategic goals have to be controlled permanently and in a systematic way. Strategic control which is part of strategic management monitors premises of the corporate strategy and the environment of the enterprise in order to evaluate whether the strategic positioning is still appropriate or whether the strategy has to be adopted due to changes in constraints. This paper shows how the enterprise architecture of an enterprise can be used as an instrument of strategic control. Strategic control is characterized by a high demand on information. Hence one needs to know where needed information is to gather. Enterprise architecture which is enriched by results and information of strategic management process is a helpful instrument in delivering information respectively the source of gathering information used in strategic control. In particular for each enterprise architecture layer a proposal is given how strategic control can be supported. 1 Introduction Enterprise Architecture (EA) is used in enterprises in many different ways [ARW08]. Regardless of concrete use the goal of EA is to create an IT environment which is focused on the corporate strategy [Mi08]. Hence it is mandatory that the strategic positioning of an enterprise is reflected in the EA in order to be of any value to the enterprise [Bo10]. The goals of an EA and in particular the goals of business information systems have to match with the overall strategic goals of the whole enterprise. Therefore it is essential to design and if necessary to redesign the EA within the strategic management process [Go06]. Thus information about the process of strategic analysis and choice are implicit contained in the EA. This information, in turn, can be used in strategic control. Premises which are defined within the process of strategic planning are the fundament of a corporate strategy [BS95]. The strategic positioning of an enterprise is established on 9 those premises. Therefore it is of strategic importance to first document these premises carefully and second to monitor them permanently. Should there be changes in premises, strategy might be adopted respectively modified. SAAT ET AL. state, that external forces such as changes in premises are “beyond the scope of EA models” [SAG09, p. 4]. Nevertheless the EA provides hints, where those changes in premises are noticed first in daily business. Another task of strategic control (see chapter 2.1) is to measure the degree of target achievement, i.e. to control whether the strategic goals of an enterprise are achieved and the intended strategy is implemented successfully. In order to measure the degree of target achievement one needs to know which processes respectively which business application systems or business units were responsible for achieving certain goals. Also in that case EA, where processes and application systems are mapped in a model, is able to provide valuable information. The research question is: How can EA support the strategic control of an enterprise? This paper introduces a research framework for answering this question. A proposal is submitted, how information from strategic management process which is needed within strategic control can be included into EA respectively into an EA model. The remainder of this paper is structured as follows: In chapter 2 conceptual fundamentals are given. The understanding of the terms strategic control and enterprise architecture is stated and related work is given. In chapters 3 - 5 the proposals for supporting strategic management in general and strategic control in particular are stated for each model layer of an EA. Chapter 6 concludes with a short summary and an outlook on further research needs. 2 Conceptual Fundamentals This chapter provides an overview of conceptual fundamentals which are basic for understanding the topic and of research work which is related to that topic. The terms strategic control and enterprise architecture are explained. Based on this understanding related approaches are stated. 2.1 Understanding of Strategic Control Strategic Control in Strategic Management Process Most of the authors in the fields of strategic management and corporate governance consider strategic control to be part of strategic management [Fr10, p. 171-176; PR94, p. 16; Ha06; SS00, p. 157]. HAHN characterizes control as an obligatory addition of any planning processes [Ha06]. Strategic control therefore contains the control of strategic planning respectively strategic maps. Strategic control does not start at the end of the planning and implementation process but at the very beginning of the strategic management process. As soon as assumptions within the strategic planning process are made, those so-called premises have to be overseen [SS87]. “Strategic control is concerned with tracking a strategy as it is being implemented, detecting problems or changes in its underlying premises, and making necessary adjustments.” [PR94, p. 381]. 10 Hence strategic control has to be forward-looking since the end result of a strategic process is “still several years off” [PR94, p.381] and realized parallel to planning and implementation processes [Ha06]. Figure 1 clarifies this meaning of strategic control. Figure 1: Strategic Control in strategic management process Types of Strategic Control STEINMANN and SCHREYÖGG distinguish between three types of strategic control: premise control, implementation control and strategic surveillance [SS87]. “Premise control is designed to check systematically and continuously whether the premises on which the strategy is based are still valid.” [PR94, p. 382]. Thus premise control is focused on noticing changes in premises as early as possible in order to allow an early shift in strategy if necessary. Implementation control checks milestones during strategy implementation in order to recognize deviations from the chosen strategic course [SS87]. Strategic surveillance finally is defined by STEINMANN and SCHREYÖGG as an unfocused control. The environment of an enterprise and the enterprise´s resources are to be monitored for information which could be threats but also opportunities for the enterprise´s continuity. Problems of Strategic Control One thing all types of strategic control have in common is a high demand on information. The kind of desired information is known whereas the source of information gathering is partly unknown or undefined within an enterprise. Once it is known who or what (e.g. a business application system) is responsible for collecting the desired information and where they occur first, the enterprise´s management can respond quickly to threats or opportunities. A quick respond to market movement is an important strategic competitive advantage. Besides for instance predefined milestones in the strategic implementation process it is hardly possible to determine ahead at which time which information has to be gathered [SS00, p. 248f]. Nevertheless the strategic course has to be monitored in a structured manner. The EA of a company can make a valuable contribution to this. Before making proposals for that, the understanding of enterprise architecture in this paper is given. 2.2 Understanding of Enterprise Architecture A common definition for EA is not given in the business information systems community so far. In this paper the understanding of architecture as “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution” [IEEE00] 11 follows the definition by the IEEE. Hence EA is understood as the fundamental organization of an enterprise. An EA can only be established successfully in an enterprise if it is considered being a means to an end. “Architecture is a means, and should not become a goal itself“ [Op09, p. 45]. OP´T LAND ET AL. state EA amongst others as a mean “within strategic Business/IT-Planning” and “to align strategic objectives and IT” [Op09, p. 40]. Every intended use should create value to an enterprise. The benefit of an EA will be the greater the stronger EA is positioned in accordance to goals and objectives of an enterprise. An EA model maps the components of an enterprise, relationships within an enterprise and to the environment into a model. There are various approaches for EA modelling. Most frameworks for EA modelling disperse the core artefacts of EA to five layers in order to reduce complexity [WF07]: Business architecture, Process architecture, Integration architecture, Software architecture and Technology architecture. The methodological foundation of this approach is the Semantic Object Model (SOM) by FERSTL and SINZ [FS95; FS06], which is an object- and business process-oriented methodology for modelling business systems. In the SOM EA the core artefacts identified by WINTER and FISCHER [WF07] are comprised in three model layers: (1) enterprise plan, (2) business process model and (3) resource model (see figure 2). Figure 2: SOM enterprise architecture [FS06, p. 349] Business objects at the business process model layer have to fulfil goals and objectives which are deduced from the enterprise plan layer. Furthermore the SOM methodology provides a concept for explicitly linking business application systems to business process models [FS06]. Hence information from strategic management process can be considered continuously from enterprise plan to business application systems. Strategies respectively strategic goals are initially specified at the first layer of the SOM EA. Premises of a corporate strategy are not modelled at all in any EA model so far. 12 2.3 Related Work The design of an EA should be a task of the enterprise´s strategic management. ROSS ET AL. even claim, that enterprise architecture should be a strategy itself [RWR06]. Most researchers position the design of EA in the strategic planning process [Op09, p. 40; RA09; Go06]. In accordance to that BOUCHARAS ET AL. identify in a broad literature review as benefits of EA “better strategic planning” and “Decision Making” [Bo10]. Thus EA is considered to be of value in the strategic planning process. SMOLANDER ET AL. suggest the metaphor that architecture represents decisions [SRP08]. Following this metaphor EA represents management´s decisions, esp. strategic planning decisions. A benefit of EA in strategic control in contrast is barely mentioned. An extensive literature review of publications in journals of the AIS1 Senior Scholars´ Basket of journals brought no hits searching for articles linking EA and strategic control. There have been some research works, especially within the TEAR2-workshops, concerning the benefits of EA. The main focus of articles reviewed by BOUCHARAS ET AL. in the paper „The Contribution of Enterprise Architecture to the Achievement of Organizational Goals“ lies on empirical studies analysing the benefit of EA in practice [Bo10]. However strategic control cannot be identified as a context, for which EA is of value. Possibly it is because, to the best of my knowledge, the potential benefit of EA to strategic control has not been analysed so far. 3 Supporting Strategic Control by the Enterprise Plan In this chapter a proposal is introduced how information generated and used in strategic management process (in the following called ‘strategic information’) can be integrated in EA models and in turn can be used in strategic control. The following focuses on the enterprise plan layer of the EA model (see fig. 2). The proposals for supporting strategic control by other layers of the EA are given in chapters 4 and 5. Studies show that premises, the underlying assumptions of every strategy, are not documented well [BP03]. But documentation is required in order to check the premises within strategic control whether they are still valid or changes have occurred. Furthermore goals of business information systems should coincide with the strategic positioning of an enterprise. Therefore premises as well as strategic goals should be documented in the enterprise plan layer. The enterprise plan of the SOM methodology takes an outside perspective onto the business system [FS06]. In the system of objectives and goals, which is the behavioural view of the enterprise plan, the planned strategies, goals and objectives as well as constraints are modelled. FERSTL and SINZ do not provide a metamodel for the design objects of the enterprise plan layer, since the modelling of the SOM methodology focuses on the second and third layer of the SOM EA. But in order to document information needed in strategic control in a structured manner a formal description of 1 2 Association for Information Systems Trends in Enterprise Architecture Research 13 premises and strategic goals is needed. Therefore following classification is introduced which leads to the metamodel in figure 3. The relationship between strategies, strategic goals, measured values and actions bases on the concept of the Balanced Scorecard by KAPLAN and NORTON [KN97] which is a management tool for translating strategy into action. Premises are assumptions on which a strategy is based on (see chapter 2.1). A premise can be basis of several strategies and a strategy usually bases on more than one premise. A premise is a specific constraint. There exist further constraints, e.g. regulation on taxation or accounting. Those constraints are out of focus here because they affect all competitors in the same way and are not assumptions of strategic positioning. Premises can be further differentiated into critical and non-critical premises or internal and external premises. This can be modelled either as another meta object or as attributes. A strategy aims one or more strategic goals. Conversely a strategic goal can be assigned to several strategies. A strategic goal is a specific goal. Besides strategic goals there are also operational goals, for example. Since in this paper information used in strategic management is considered, other than strategic goals are out of focus. A goal can be split into sub goals. Goals respectively their achievement are restricted by constraints. For every goal at least one measured value has to be defined which measures the degree of goal achievement. A measured value belongs to exactly one goal. A target value is given to each measured value as an attribute of this meta object. In order to operationalize a strategy for every goal at least one action is defined. An action in turn can contribute to achieve several goals. Figure 3: Metamodell for the considered part of the enterprise plan layer This metamodel is the basis for supporting strategic control by EA, since strategic information is initially attached to the top layer of the EA model. Further layers are modelled under consideration of this strategic information. Next an example for illustration purposes is introduced. e-Car plc. is a company that deals with electric cars. The company entered the German automobile market recently. Table 1 shows an excerpt from strategies and underlying premises which were defined by the management of e-Car plc. This example is a modification and extension of the example given in [LWF10]. 14 Premise A new product can only be launched on the market at a moderate price level Growing demand for electric cars Government aid for electric cars remains until 2014 Strategy Cost leadership Growth strategy Cost leadership Table 1: Example premises and strategies Figure 4 shows the relationship between strategic goals, actions, measured values and target values as an extension of the metamodel defined above: A top-level strategic goal is to “be a reliable partner”. In consideration of the strategies (see tab. 1) a subgoal is e.g. “pay on time”. The achievement of this goal is evaluated by the measured value “date of payment”. Target value for goal achievement is “one day before the contractual date of payment”. In order to achieve this goal the action “diligent billing management” should be implemented. Figure 4: Modelling of strategic goals at enterprise plan layer 4 Supporting Strategic Control by Business Process Models At business process model layer solution procedures for realizing the enterprise plan are specified [PS10]. That means that the implementation of the corporate strategy is modelled. Hence the defined actions in the enterprise plan have to be reflected in the business process model. Premises and strategic goals defined in the enterprise plan should be mapped to certain business objects in order to clarify which business object is responsible for putting defined actions into practice and for delivering which strategic 15 information. Before this mapping is explained in detail a short introduction into the modelling method of the SOM methodology is given. In the SOM methodology there exist two views of a business process model. “The interaction schema is the view on structure” whereas the “task-event schema is the view on behavior” [FS06]. Strategic goals and constraints are only modelled in the structural view. In the interaction schema business objects and business transactions which transmit goods, services or messages between these business objects are modelled. A short example illustrates the modelling method. The negotiation between a company and a customer consists of an initiating transaction (i), a contracting transaction (c) and an enforcing transaction (e). Fig. 5 shows the structure of this business process. Figure 5: Interaction schema 4.1 Modelling of strategic goals In strategic control the achievement of strategic (interim) goals is monitored. Furthermore it is checked which actions put into practice successfully and which actions missed their targets. Hence strategic goals and their sub goals have to be mapped to business objects. These business objects are then responsible for translating these goals and for implementing assigned actions. In the SOM methodology every business object has to fulfil goals and objectives which are given by a management object. Goals and objectives in general and strategic goals in particular are modelled as follows. A management object (e.g. “Management” in fig. 6) sets goals and objectives of an operational object (e.g. “Production” in fig. 6). This goal relation is modelled as “g”-transaction. The operational object in return informs the management object about the degree of goal achievement [FS06]. Example e-Car plc.: The two top-level goals “Be a reliable partner” and “Profit maximization” are mapped to the business object “Management” (see fig. 6). The subgoals are assigned adequately by this management object to the operational objects “Production“ and “Sales”. For example, the subgoal “Pay on time” has to be fulfilled by the business object “Production”. 16 g: P g: ay o D g: eliv n tim Go ery e g: Lo od q on t w C ua im l os ity e ts me olu s v ime t ale h s on Hig ery g: eliv D g: Figure 6: Modelling of strategic goals at business process model layer Every action can be mapped to a transaction of the business process model [Me96, p. 153]. The result of an action is a service which is performed either by the sender or by the receiver of a transaction. Example e-Car plc.: Action Quality aspects are part of contracts with delivers Diligent billing management Service Working out adequate contracts Transaction c: PO preproducts Registration of invoices immediately and check by a second person c: invoice Table 2: Actions and transactions The action “Quality aspects are part of contracts with delivers” (goal: Good quality) has to be implemented by working out adequate contracts, which is prerequisite for the transaction “PO pre-products”. The business sub object “Procurement“ sends this transaction. The action “Diligent billing management” (goal: Pay on time) is applied through registration of invoices immediately and checking by a second person whenever the transaction “invoice” reaches the business sub object “Production finance” (see tab. 2 and fig. 7). For the sake of clarity, modelling of measured values and target values in the business process model are omitted. For modelling objectives and therefore for mapping them form enterprise plan layer to business process model layer rules are defined, e.g.: " " A modelled goal in the business process model has to correspond to a goal defined in the enterprise plan respectively has to be assigned to a goal as a sub goal. (Secures continuous goal-orientation and consistency) A strategic goal and corresponding actions have to be linked in the same business object respectively in a controlled business object. (Secures that a business object is able to achieve the strategic goal) 17 g: Good Quality g: g: Pay g: Deli on g: Goo very time Lo d w q u o n ti Co ali m e sts ty g g :P pu : F a ay o rc vo n ha ra tim se ble e g: g: Hig De h s liv ale er y o s vo n t lum im e e g: g: Goo De d liv qua er y o lity nt im e Figure 7: Modelling of actions at business process model layer (excerpt, transactions within “Production” are omitted) Modelling strategic goals and assigned actions in this detailed way ensures that business processes are aligned to corporate strategy. 4.2 Modelling of Premises Another important task of strategic control is to monitor the premises of strategies. The question raises how and where those premises are to be monitored and who is responsible for that. SCHREYÖGG and STEINMANN suggest the business unit which is factual competent to monitor premises. [SS00, p. 249]. Thus premises are attached to business objects in the business process model following the rules: " " Which business object notices a change of a premise first? In which transaction between business objects can a changing premise be noticed first? For modelling premises the notation of modelling context of business systems is adopted. WAGNER and FERSTL define the context of business objects and transactions as “influencing factors of their environment which are not already modelled in transactions“ [WF09, p. 4]. Hence context is understood as specific constraints of entrepreneurial activities. Since premises are also understood as constraints the use of this notation is justified. 18 Figure 8: Modelling of premises at business process model layer Example e-Car plc.: The premise “Growing demand for electric cars” is characterised by a high number of requests and orders. These transactions reach the business object “Sales” (see fig. 8). The premise “A new product can only be launched at a moderate price level” is overseen by the same business object through analysing the realized sales numbers and prices. In the decomposition of the business object “Sales” premises can be attached to the business sub objects „Sales administration“ and “Sales management” (see fig. 9). The premise “Government aid remains until 2014” has to be overseen by the management of e-Car plc. g g g g g Figure 9: Modelling of premises at business process model layer - refinement (excerpt, transactions within “Sales” are omitted) For modelling premises and therefore for mapping them from enterprise plan layer to business process model layer rules are defined, e.g.: 19 " " Premises which are not modelled in the business process model layer are to be monitored by the management (e.g. business object “Management“ in figure 8). A premise can also be attached to more than one business object. Once it is known which business objects have to monitor which premises the business objects are then responsible for the way they monitor premises. Business application systems can support this monitoring (see chapter 5). A procedure for dealing with changed premises has to be defined by corporate governance, which is out of focus here. 5 Supporting Strategic Control by Business Application Systems Software development projects, thus also development projects of business application systems supporting business processes, fail frequently because of lacking goal synchronization between software development project goals and goals of the whole enterprise [BM11]. Therefore it is necessary to take strategic goals during specification of the business application system into account. The third layer of the SOM EA (see fig. 2) comprises the resource model. It “describes the actors for carrying out the business tasks of the business system” [PS10, p. 59]. Those resources are needed for execution of business processes. Besides the specification of business application systems also the organization of personnel is specified. The latter is not considered in the following since this is a classical field of organization theory. Nevertheless considering the strategic positioning of an enterprise is also very important in personnel decisions. The better the first and second layer of the SOM EA is modelled and the more information about strategic positioning is included, the stronger business application systems will be aligned to strategic goals, which is an important contribution to Business-IT-Alignment. In a business process model goals are attached to single business objects. One or more business objects are linked to one business application system. I.e. the linked business application system supports the execution of the business processes. For more information how derivation is done in detail see [FS06]. Therefore it is explicitly specified that a business application system has to support the goals respectively the actions which are attached to the business objects linked to this application system. If the measured value of these goals can be measured automatically then checking the degree of goal achievement is easy. E.g. if the payment process is IT-supported then it can be automatically checked, whether the outstanding accounts of the business object „Production finance“ are paid one day before the date agreed on in the contracts (see fig. 7). The same is true for the desired information in strategic premise control. Premises are also attached to business objects und therefore - if changes in premises can be determined automatically - also to one or more business application systems. An example would be the number of queries respectively conclusions of contract which are directed to the business object “Sales administration” via a web shop (see fig. 9). 20 6 Summary and Outlook Detailed information about the parts of an enterprise and their relationship to each other are included in the EA. Enriched by information from strategic management process the EA can be a valuable instrument of strategic control. The paper on hand introduces a proposal how information respectively the source of gathering information needed in strategic control like changes in premises or responsibility for achieving strategic goals can be taken from the EA. The other way round putting information from strategic management process into all layers of an EA model ensures that business process models and business application systems are going along with the strategic positioning of an enterprise. An essential prerequisite for EA being an instrument of strategic control can be deduced from that: The EA has to be developed within the strategic management process and has to be adopted when changes in strategy are made. Further need for research is necessary in defining this involvement in the process of strategic management. Furthermore tool support in modelling strategic information at all layers of the SOM enterprise architecture is needed. Tool-supported modelling of EA especially documenting premises and strategic goals in an enterprise architecture tool is mandatorily required for understanding a strategic positioning of an enterprise in order to follow this positioning in further modelling of the EA. References [ARW08]Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur - Literaturüberblick und Stand der Praxis. In Wirtschaftsinformatik, 2008, 50; pp. 292–304. [BM11] Buhl, H. U.; Meler, M. C.: Die Verantwortung der Wirtschaftsinformatik bei ITGroßprojekten. Symptome, Diagnose und Therapie. In Wirtschaftsinformatik, 2011; pp. 59–62. [Bo10] Boucharas, V. et al.: The Contribution of Enterprise Architecture to the Achievement of Organizational Goals: A Review of the Evidence. In (Proper, E. et al. Eds.): Trends in Enterprise Architecture Research. 5th International Workshop, TEAR 2010, Delft, The Netherlands, November 12, 2010. Proceedings. Springer, Berlin, Heidelberg, 2010; pp. 1-15. [BP03] Becker, W.; Piser, M.: Strategische Kontrolle. Ergebnisse einer empirischen Untersuchung. Otto-Friedrich-Universität, Bamberg, 2003. [BS95] Band, D. C.; Scanlan, G.: Strategic control through core competencies. In Long Range Planning, 1995, 28; pp. 102–114. [Fr10] Freeman, R. E.: Strategic management. Univ. Press, Cambridge, 2010. [FS95] Ferstl, O. K.; Sinz, E. J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. In Wirtschaftsinformatik, 1995, 37; pp. 209–220. [FS06] Ferstl, O. K.; Sinz, E. J.: Modeling of Business Systems Using SOM. In (Bernus, P. Ed.): Handbook on architectures of information systems. Springer, Berlin, 2006; pp. 347–367. [Go06] Goethals, F. G. et al.: Management and enterprise architecture click: The FAD(E)E framework. In Information Systems Frontiers, 2006, 8; pp. 67–79. 21 [Ha06] Hahn, D.: Strategische Kontrolle. In (Hahn, D.; Taylor, B. Eds.): Strategische Unternehmungsplanung - Strategische Unternehmungsführung. Springer-Verlag Berlin, Heidelberg, 2006; pp. 451-464. [IEEE00] IEEE Computer Society: IEEE Recommended practice for architectural description of software-intensive systems, New York, 2000. [KN97] Kaplan, R. S.; Norton, D. P.: The balanced scorecard. Harvard Business School Press, Boston, Mass, 1997. [LWF10] Leuning, B.; Wagner, D.; Ferstl, O. K.: Hochflexible Geschäftsprozesse in der Logistik ein Integrationsszenario für den Forschungsverbund forFLEX. Bayerischer Forschungsverbund Dienstorientierte IT-Systeme für hochflexible Geschäftsprozesse (forFLEX), Bericht-Nr. forFLEX-2010-001, 2010. [Me96] Mehler-Bicher, A.: Ein objekt- und geschäftsprozeßorientiertes Architektur-modell für Management-Support-Systeme. Tectum-Verl., Marburg, 1996. [Mi08] Minoli, D.: Enterprise architecture A to Z. CRC Press/Taylor & Francis, Boca Raton, Fla., 2008. [Op09] Op't Land, M. et al.: Enterprise architecture. Creating Value by Informed Governance. Springer, Berlin Heidelberg, 2009. [PR94] Pearce, J. A.; Robinson, R. B.: Strategic management. Formulation, implementation, and control. Irwin, Burr Ridge, Ill., 1994. [PS10] Pütz, C.; Sinz, E. J.: Model-driven Derivation of BPMN Workflow Schemata from SOM Business Process Models. In Enterprise Modelling and Information Systems Architectures, 2010, 5; pp. 57–72. [RA09] Riege, C.; Aier, S.: A Contingency Approach to Enterprise Architecture Method Engineering. In (Lamersdorf, W.; Feuerlicht, G. Eds.): Service-oriented computing ICSOC 2008 workshops. ICSOC 2008 international workshops, Sydney, Australia, December 1, 2008 ; revised selected papers. Springer, Berlin, Heidelberg, 2009; pp. 388–399. [RWR09] Ross, J. W.; Weill, P.; Robertson, D. C.: Enterprise architecture as strategy. Creating a foundation for business execution. Harvard Business School Press, Boston, Mass., 2009. [SAG09] Saat, J.; Aier, S.; Gleichauf, B.: Assessing the Complexity of Dynamics in Enterprise Architecture Planning - Lessons from Chaos Theory. AMCIS 2009 - Proceedings of the 15th Americas Conference on Information Systems. San Francisco, California, 6-9 August 2009. [SRP08] Smolander, K.; Rossi, M.; Purao, S.: Software architectures: Blueprints, Literature, Language or Decision? In European Journal of Information Systems, 2008, 17, pp 575588. [SS87] Schreyögg, G.; Steinmann, H.: Strategic Control: A New perspective. In Academy of Management Review, 1987, 12; pp. 91–103. [SS00] Steinmann, H.; Schreyögg, G.: Management. Grundlagen der Unternehmensführung; Konzepte, Funktionen, Fallstudien. Gabler, Wiesbaden, 2000. [WF07] Winter, R.; Fischer, R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In Journal of Enterprise Architecture, 2007; pp. 1–12. [WF09] Wagner, D.; Ferstl, O. K.: Enhancing Flexibility and Precision of Enterprise Architectures by Modeling Context-Aware Business Processes. Bayerischer Forschungsverbund Dienstorientierte IT-Systeme für hochflexible Geschäftsprozesse (forFLEX), Bericht-Nr.: forFLEX-2009-003, 2009. 22 Towards a More Integrated EA Planning: Linking Transformation Planning with Evolutionary Change Stephan Aier1, Sabine Buckl2, Bettina Gleichauf1, Florian Matthes2, Christian M. Schweda2, Robert Winter1 1 Institute of Information Management, University of St. Gallen Müller-Friedberg-Strasse 8, 9000 St. Gallen, Switzerland {stephan.aier | bettina.gleichauf | robert.winter}@unisg.ch 2 Chair for Software Engineering of Business Information Systems (sebis), Technische Universität München Boltzmannstr. 3, 85748 Garching, Germany {sabine.buckl | matthes | christian.m.schweda}@mytum.de Abstract: Enterprises are subject to continuous change driven by top-down planned transformation projects as well as by bottom-up initiatives realizing what is called the evolution of the enterprise. Enterprise architecture (EA) planning presents itself as a means for facilitating and controlling this change. Nevertheless, the methods and models of EA planning developed in recent years either have a strong focus on planned (proactive) transformations or on guided (reactive) evolution. In this paper, we outline an EA planning method that accounts for both types of enterprise change by illustrating the interplay of EA planning, requirements, release, and synchronization management. Specifically we focus on the coordination of design activities modeled as intermeshed closed-loop control systems and on an integrated information model describing EA transformation planning. Keywords: Enterprise architecture planning, methods, models, techniques 1 Introduction Today’s enterprises find themselves confronted with ever changing economic, regulatory, and technical environments that they are forced to continuously adapt to [RWR06], [Wa05]. Performing changes that are necessary or help to leverage idle opportunities is a complex task, aggravated by the intricate and highly interwoven architecture of the overall organization. Thereby, architecture or enterprise architecture (EA), respectively, is understood as the “fundamental organization of a system [the enterprise] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution” [IOS07]. A commonly accepted instrument to guide enterprise transformations is EA planning, whose main goal is to enhance and maintain the mutual alignment of business and IT [HV93], [LLO93]. Effectively established, EA planning as part of an EA management (EAM) function provides an organization-wide perspective on change, making the impact of projects on EA elements transparent. While business is commonly seen as the driver of organizational change, projects are the implementers and by their nature a 23 cross-cutting aspect. Changes to an enterprise can be differentiated into evolution (incremental change, usually bottom-up driven) and transformation (fundamental change, usually top-down driven). Whereas support for the former type of change is typically provided by functional methods of business administration, e.g. human resources, distribution, or marketing, the latter requires a holistic management function to systematically support organizational transformation [Wi08]. Although EA planning is commonly regarded as a core capability of EAM [Pu06], only a few authors propose well-engineered methods and models for EA planning. Especially, the need to integrate EA planning with existing management functions like enterprise-wide requirements management or project portfolio management to derive consistent transformation plans as well as synchronization management to implement changes is not considered in existing approaches. Therefore, this paper contributes to the field of EA planning by answering the following research questions: ! How can top-down driven, planned transformation and bottom-up driven guided evolution of the enterprise be consistently integrated in EA planning? ! Which methods or conceptualizations from related disciplines (requirements, project portfolio, and synchronization management) are suitable for consistently planning transformation and evolution aspects of enterprise change? In order to answer the above questions, we follow the identify problem/motivate – define objectives – design – demonstrate – [evaluate] process by [Pe07]. Section 2 motivates the need for an integrated EA planning method and model and derives relevant requirements. Prefabrics from the areas of EA planning, change, and requirements management as well as project portfolio, and synchronization management are revisited in Section 3. Our artifact – a method for integrated EA planning – is presented in Section 4. The theoretic discussion on the artifact is complemented in Section 5 by a case study, which serves as a demonstration and initial evaluation 1. Finally, Section 6 critically reflects our contribution and provides an outlook on further research. 2 Deriving requirements for integrated planning Matthes et al. conducted a survey on the state-of-the-art in EAM tools [Ma08]. Central means of analyzing these tools is a set of nine “scenarios” that describe typical activities of EAM. The scenario descriptions provide core concerns on an abstract level which are further concretized with questions that are to be answered in performing the activity. While initially developed as a set of requirements for analyzing EAM tools, the scenarios also provide a basis for deriving requirements for an integrated EA planning method and underlying model. In short the methodology for scenario elicitation can be summarized in five steps as follows [Ma08]: ! Derive initial scenario description from project experiences, scientific literature, and end-user input 1 Although our demonstration is based on a real industry case, it is not hold a full evaluation. However, this single case provides support for the proposed artifact to justify its discussion in the scientific community by this publication. 24 ! Conduct on-site workshops with the survey’s industry partners ! Revise scenario descriptions to on-site feedback provided by reviewers and add or reshape scenarios appropriately ! Conduct remote review round with industry partners of the survey ! Revise scenario descriptions to feedback Following this methodology, a comprehensive set of scenarios based on existing literature and further leveraging the knowledge of 30 user companies has been compiled. Three of these scenarios are essential for EA change processes, namely enterprise-wide requirements management, project portfolio management, and synchronization management. In the following the concerns of these scenarios are briefly summarized and the corresponding questions are reformulated as requirements for an integrated EA planning method and underlying model. Enterprise-wide requirements management is concerned with gathering and documenting the requirements raised at different times and in different parts of an organization. A requirement describes a desired state of an organization’s EA or part thereof. Affected EA elements can reside on all EA layers from business to infrastructure. In the management process these requirements are classified in respect to their urgency and are grouped by affected EA elements. Thus, typical requirements of enterprise-wide requirements management read as follows: (R1) Collect and document requirements in a uniform way (R2) Categorize requirements in respect to their urgency (“must” vs. “may”) (R3) Link requirements to affected EA elements (R4) Derive project proposals from requirements Project portfolio management decides which project proposals are executed as projects in the next planning period. The process plans a short term future state of the EA based on various measures and takes a transformation-centric perspective by analyzing which EA elements are changed by which project. By doing so, the management process diagnoses potential for alignment between change activities. Such analyses can uncover that a project targets optimizations to an element which is conversely retired by another project. Project portfolio management raises the following requirements: (R5) Estimate project proposals’ costs and economic impact (R6) Analyze and resolve dependencies between transformation and evolution project proposals targeting the same EA element (R7) Ensure that urgent project proposals are prioritized high and scheduled on short time initiation (R8) Assign and distribute project budgets Synchronization management establishes a common time-schedule for approved projects respecting their interdependencies. In particular, projects that aim at affecting the same EA elements at the same time but may not be integrated into a single project are re- 25 scheduled to minimize project interplay. Synchronization management further is no onetime activity but has to continually track project states such that actions for re-scheduling can be taken early, if necessary. Thus, the following requirements can be derived: (R9) Schedule projects to minimize pertaining EA-induced interdependencies (R10) Control project progress and re-schedule in case of project delays Reflecting our research questions (see Section 1) requirements (R1), (R3), (R4), (R6), and (R9) are of interest and are addressed by our method and model. 3 Preliminary and related work The question of engineering enterprise transformation using EA models has been addressed in detail by [AG10b]. However, [AG10b] do not consider evolutionary bottomup change initiatives that may occur on a local project level. We aim at enhancing the existing method towards an integrated approach that reflects methods and models from enterprise-wide requirements, project portfolio, and synchronization management (R1) and thus integrates centrally derived transformation plans as well as locally triggered evolutionary change (R6). Figure 1 shows how EA planning depends on other processes. Requirements Management Product Portfolio Management Business Process Management Application Portfolio Management IT Infrastructure Management requirements EA Management Business and IT Strategy Development as-is models strategic requirements EA Planning EA As-Is Documentation potentials EA Analysis EA principles, to-be models, project descriptions as-is state as-is EA Implementation Release Management Project Portfolio Management Synchronization Management Figure 1: Contextual diagram of the EA planning process [AG10a] The EA planning process is one of several EAM processes, complementing EA as-is documentation as well as EA analysis processes. EA planning is driven by requirements from the different sub-architectures. As the planning process is based on EA models, information about as-is models and condensed information from EA analysis is needed. Besides that, strategic principles from business and IT strategy processes guide the EA planning process. Main outputs of the planning process are to-be models of future architecture states as well as project descriptions about development projects that will implement the planned enhancements. Those project proposals are accompanied by EA principles that are developed within the EA management processes and distributed into im- 26 plementation processes via EA planning. The actual implementation is then controlled by release, project portfolio, and synchronization management processes. From there, information about the as-is state of EA is fed back to EA management and to subarchitectures’ management processes. In Subsection 3.1 we will review approaches for top-down transformation planning. In Subsection 3.2 we will complement these by approaches for bottom-up planned evolutionary change. 3.1 Top-down transformation planning [AG10a] present a method for EA transformation that puts emphasis on the method’s “outputs” as well as on their interdependencies. The result of the first step of the method is a list of EA elements that need to be changed in order to reach the targeted to-be state (R3). Those EA elements are the core subjects of transformation activities. Additionally, as EA elements must not be considered as stand-alone artifacts, information about their relationships to other EA elements needs to be captured as well. Thus, the method produces a list of predecessor/successor relationships linking the as-is with the to-be state, as a basis for plan development activities. These relationships are covered in a transformation model. The second step plans transformation in detail. The step’s result is a description of project proposals (R4) containing a list of preconditions, a list of affected EA elements and a relative time line that respects individual life cycles of and temporal interdependencies between EA elements (R9). Based on these proposals actual projects can be defined in a third step, taking available budgets and resources into account. The analysis of differences in the as-is and the to-be state identifies successor relationships between model elements which represent successor relationships of enterprise artifacts, more precisely of their lifecycle phase “in production”. From there, the general dependencies of pre-production and decommissioning lifecycle phases can be derived for each segment. The actual sub-division of such pre-production phases varies depending on the type of artifact considered and may comprise various development activities, including specification or testing. Preceding analyses should be grounded in an according information model describing the concepts of the enterprise and the transformation model. [Bu09] have presented such a model introducing the notion of ProjectAffectable and applying it to the EA model concepts business application and business support, respectively. Figure 2 shows an adapted version of this model, which also accounts for temporality aspects of EA planning. Thereto, the start and end dates of the projects’ work packages are temporal attributes in the sense of the corresponding pattern of [CEF99]. This means that the transformation model can change over time entailing an adaptation of the duration of the work packages (R10). 27 Figure 2: Information model adapted from [Bu09] The next steps of the EA planning method aim at scheduling an effective sequence of development activities upon the affected artifacts (R9). Therefore, the change-induced relationships between the model elements must additionally be taken into account. A temporal restriction, for example, may arise, if a new business process is to be introduced in the to-be state and the supporting applications must be developed before the business process can be activated. Additionally, individual model element lifecycles that might be affected, for example, by vendor support must be respected and integrated. Scheduling the development activities and establishing the transformation model can be supported by planning techniques from the field of project management. Gantt or milestone charts are commonly used to represent schedules. However, these techniques lack in showing interdependencies between activities and events, which is provided by network techniques [Ke09]. Among such techniques to construct project network diagrams, the Project Management Institute mentions the Precedence Diagramming Method and the Arrow Diagramming Method that are able to display temporal dependencies between individual activities [PMI00]. Based on project network models, formal analyses can be applied to determine actual dates for project plans. A common technique is the Critical Path Method that calculates deterministic early and late start and end dates for each activity, based on an activity-on-node network [AW90]. 3.2 Bottom-up planned evolutionary change In classic software development requirements engineering is understood as a process to create and maintain a high-level requirements document for a system (R1). According to Sommerville [So01] any requirements engineering process is comprised of four activities. Feasibility studies are conducted against the background of an initial set of requirements to answer whether the system under consideration contributes to the overall objective of the organization and whether a system can be implemented within the current technological and economic constraints. Based on the answers to the preceding questions system requirements are subsequently (requirements elicitation and analysis) discovered in cooperation with the stakeholders. These requirements are classified and organized into groups of related and mutually coherent requirements. Preceding their documentation in a requirements specification document, the requirements are prioritized and negotiated upon. During requirements validation different kinds of checks are performed using multiple techniques as systematic or formal review. Thereby, checks for internal validity (consistency), external validity (completeness and realism), and quality (verifiability) are performed on the requirements specification. 28 Proceeding from one-time requirements engineering in a software project to requirements-related processes for a long-living software solution, one comes to the discipline of requirements management [So01]. In the single-system environment of classical software engineering the corresponding change management process boils down to three essential activities of identifying a change proposal, analyzing the proposed change with respect to costs and feasibility, and implementing the change. The IT Infrastructure Library (ITIL) [OGC00] furthers this basic understanding of change management by introducing additional steps for authorizing change, which form a counterpart of the feasibility analysis discussed by [So01]. Further, ITIL adds a post implementation review, which in line with classic software engineering may be understood as revising the requirements specification. Release management is primarily understood as the process of making software available to its users. What at first sight seems to be an easy task is aggravated by the complex interdependencies of modern component-based software. [HW03] discuss five requirements that release management has to satisfy: 1) make component dependencies explicit, 2) keep releases consistent with respect to these dependencies, 3) control user access to a release, 4) support development team transparently, and 5) store history of releases and their usages. Key concept of release management is component metadata, i.e. specifications on dependencies between components, but also on dates of release and of withdrawal. After an internally and externally validated set of requirements has been converted to an agreed project portfolio (R4), synchronization management aims at the interdependencies between the changed projects (R9). [ES10] describes a method for identifying such dependencies exemplified along the following three types of dependencies: 1) organizational dependencies, resulting from multiple projects targeting the same part of the organization at the same time, 2) interface dependencies, resulting from the need to migrate applications’ interfaces simultaneously with changing the related applications, and 3) technical dependencies, resulting from infrastructure dependencies of applications, e.g. the compatibility with only distinct operating systems. 4 An integrated method for EA planning The artifact of the paper at hand is an integrated method [MS95] for EA planning taking global top-down driven transformation plans as well as local bottom-up driven evolution of partial architectures into account. A method consists of a sequence of design activities which are related to a procedure model. The produced design results of the design activities are represented by an information model. Additionally, a method consists of roles which describe the participants involved in the design activities. At the same time the inclusion of roles introduces various perspectives different stakeholders may have on design activities. Instructions on how the design results are produced and documented are provided by adequate techniques [Br05], [Gu94]. 29 Our analysis of related work shows that all of the relevant requirements (Section 2) but (R6) are addressed by preliminary or related work described in Section 3. Our analysis also shows that general planning cycles for global EA transformation plans on the one hand side and more local requirements, release, and synchronization management on the other hand side are similar. While the granularity of their planning objects differs (and thus the approaches’ formality) their activities and techniques are similar. The main challenges for an integrated planning approach are its organization and coordination as well as its consistent description in an information model (R6). Therefore, this contribution focuses on the coordination of design activities (Subsection 4.1) and on an integrated information model (Subsection 4.2). 4.1 Coordination mechanisms Deriving consistent and integrated plans for EA transformation and evolution is a complex task because ! a number of subsystems (represented e.g. by architectural layers) need to be coordinated and the subsystems are again complex, ! a number of stakeholders responsible for one or more subsystems need to be coordinated, thus the task can only be solved by division of labor, ! neither the (sub) system(s) nor its environment(s) can be expected to remain unchanged during a planning cycle and a plan’s implementation. It is unlikely to develop a consistent and integrated plan for EA transformation and evolution in a single iteration by central planning. Instead several iterations of centralized and distributed planning will be necessary. In cybernetics this situation is modeled as a closed-loop control system comprised of goal setting, (meta-)planning, controlling, running, and measuring. The measurement results are fed back to the controller who then adjusts the system’s input. If engineered properly closed-loop control systems achieve defined goals even in a dynamic environment. In case a system consists of several other systems it can be modeled as a system of intermeshed closed-loop control systems (Figure 3) [HG94]. In such a situation running system A is equivalent to (meta-)planning and controlling of system B. goals (meta) planning and controlling system A input of to-be values running and measuring system A = input of to-be values (meta) planning and feedback of as-is values controlling system B running and measuring system B feedback of as-is values input Figure 3: Closed-loop control systems based on [HG94] 30 output Systems of intermeshed closed-loop control systems are guided and controlled by 1) overall goals and 2) contracts describing the interfaces between each closed-loop control system. Overall goals are defined by business strategy, IT strategy, and EA strategy in particular. The structure of interfaces is defined by the governance structure relevant for the participants of the planning cycle. Legitimacy of each partial plan as well as the integrated solution can be evaluated based on existing EA principles. Such systems can be vertically or horizontally intermeshed. Vertically intermeshed systems can be found in hierarchical relations, e.g. overall application planning is vertically intermeshed with application planning for divisions, business units, regions, products etc. Horizontally intermeshed systems can be found with peer-level planning, e.g. application planning is horizontally intermeshed with IT infrastructure planning. As the examples above illustrate, the general approach to design an integrated EA planning function as a system of intermeshed closed-loop control systems allows for a variety of configurations. According to the Conant-Ashby theorem “every good regulator of a system must be a model of that system” [CA70] which means that the effectiveness of the individual configuration depends on how well it represents the actual interdependencies of the planning objects. The following information model ensures that the theorem is fulfilled. In Section 5 we will discuss an example configuration. 4.2 Information model Figure 4 shows an information model that is capable of describing the transformation model for EA planning in an embracing manner. Figure 4: Information model for describing the EA planning transformation model Central concept of the information model is the mixin PROJECTAFFECTABLE which marks a concept from an EA information model as subject to EA planning, thereby allowing a using organization to decide which concepts, e.g. business applications, are considered in EA planning. 31 Beyond the basic linkage between the concept REQUIREMENT and the concept WORKPACKAGE in Figure 2, the comprehensive information model introduces a different conception. Firstly, a requirement reflects an intended change in contrast to a work package that describes a scheduled change. Secondly, complementing the relationships introduces and retires that target changes on an EA-relevant level, the requirement provides the relationship optimizes. This relationship allows describing maintenance requirements that do not reshape the enterprise on an EA-relevant level. Together, the three types of relationships and the relationship precedence cover all types of dependencies between architecture elements in a uniform manner (see requirements (R3) and (R6)). In particular, they supply a basis for a technique for comparing an as-is and a tobe state (T1). Further, each requirement bears a target date, i.e. a date as of which the change is to be effective, as well as an expected duration for implementation. Based on this information, the technique of a critical path analysis (T5) can be implemented. Above information not only supplies concepts for documenting requirements, but also for documenting decisions on requirements. A requirement can on the one hand switch to the role APPROVEDREQUIREMENT, where it is further linked to a work package for implementation. On the other hand, a requirement may also be converted to a POSTPONEDREQUIREMENT to reflect that currently no plan for resolving the identified conflicts can be scheduled. Thereby, techniques for requirements management (T2) as well as techniques for synchronization management (T3) are supported via the temporal and explicit dependencies between the requirements. Table 1 summarizes design results, information model, design activities, and techniques of our method for an integrated EA planning. Table 1: Method summary Method for planning enterprise transformation Design Results DR1. Meta result [or input]: System of local and global partial plans (R1) DR2. Meta result [or input]: Coordination mechanisms (R6) DR3. Meta result [or input]: Principles and goal structures (R6) DR4. List of model elements that need to be changed in each partial plan (ProjectAffectables) (R3) DR5. Information about relationships to other model elements and other partial plans (requirement relations) (F) DR6. Description of project proposals containing work packages realizing approved requirements (R4, R9) Information Model Design Activities I1. Transformation Model (R3, R6; provides basis for T1-3, T5) A1. Analyze differences between as-is and to-be (requirements) for each local and global planning iteration (DR4) A2. Synchronize partial plans and identify inconsistencies (DR5) A3. Separate segments, i.e. identify work packages and projects (DR6) For each segment: A4. Identify general temporal interdependencies (DR6) A5. Schedule an effective sequence of development activities, by refining temporal interdependencies (DR6) A6. Draw network plan displaying all interdependencies (DR6) 32 Techniques T1. Graph comparison (for A1) T2. Techniques of requirements management (for A1) T3. Techniques of synchronization management (for A2, A3) T4. Establishing project network model/graph using Precedence Diagramming Method and the Arrow Diagramming Method (for A5) T5. Deriving a project timeline using Critical Path Method (for A5) 5 Demonstration In this section, we demonstrate (and initially evaluate) our approach employing an industry case illustrating one possible configuration of a system of intermeshed closed-loop control systems as proposed in this paper. The using company provides banking solutions, offering a banking platform to private and universal banks. The company’s EAM focuses on three main fields: Application development, application management, and operations. The application development division is responsible for the development of the banking platform which is described by an application architecture model, an IT architecture model, and an operating model. Challenges within the architectural development plan are the coordination of activities of development teams (R6), assurance that all dependencies are addressed, and that milestones of integration and development activities are met simultaneously (R9). If, for example, a component of an application needs an interface to a component of another application (R3) at a certain time for a certain milestone (e.g. test or release), it has to be assured that both components are available at that very point in time. This simple example grows very complex as the banking platform comprises over 200 applications, each consisting of a multitude of components that each has its own lifecycle. The planning activities at the company aim at the further development of their core product, a banking platform, which consists of various applications, interfaces and middleware components. As the company also provides the hosting of the platform, infrastructure is an issue, too. For this perspective, the company’s information model covers the relationships between business applications, their constituting components and the underlying hardware devices (see Figure 5). The three conceptual classes representing architecture elements are thereby considered project affectable, i.e. are subject to the dependence planning mechanisms described in our method. Figure 5: Information model of the demonstration case In such a scenario both, top-down transformation plans and the bottom-up evolution of partial architectures occur and need to be integrated (R6). Further development of the banking platform (high-level transformation plan) is driven by a superordinate planning team that defines the general development strategy of the platform and the relevant principles (DR1, DR2, DR3). At the same time requirements for the development of the individual components and sub-architectures are collected separately. The configuration 33 of the underlying intermeshed closed-loop control system is a matrix structure defined by lead architects (business, applications, IT, operations, and security) and domain architects responsible for business domains structured by business products (DR1, DR2). Partial architecture roadmaps are defined following the general EA guidelines. The roadmaps consist of models representing snapshots of the desired architecture for up to three future points in time, taking into account existing vendor specific constraints if applicable (DR4). Individual component development plans are then integrated into these roadmaps. The coordination between high-level transformation plans and local roadmaps of evolution is ensured by the matrix structure. While domain architects control the development and realization of high-level transformation plans, lead architects drive and ensure the development of components taking detailed restrictions into account. In joint workshops all parties consolidate their plans based on EA goals and principles. Possible alternatives are thereby discussed and evaluated (DR5). This particular matrix configuration uses vertical and horizontal coordination of the meshed systems. Vertical coordination occurs e.g. by aligning a domain specific transformation plan with the detailed plans for applications of that domain. Horizontal coordination occurs e.g. by aligning the partial architectures of the lead architects. To determine a sequence of development activities general milestones and components to be developed are defined. Afterwards, the development phases of the elements’ lifecycles are planned in detail, i.e. in terms of specification and testing phases. Upon those specifications a rough project program schedule can be defined (DR6). Finally, on the basis of the project outlines actual project planning is enabled. For that purpose, the project proposals can be enriched with information about costs, quality metrics, staff, risks, and resources. The case description illustrates that an appropriate configuration of a system of intermeshed closed-loop control systems that takes the concerns of relevant stakeholders (domain and lead architects) into account is a efficient solution for coordination of topdown transformation planning and bottom-up evolutionary change. Whether the results of such a planning approach justify the respective efforts cannot be shown here. Therefore, the case study does not serve as a full evaluation. However, discussions with the case study company showed that – apart from a well defined plan – such an approach has a number of positive side effects – most notably stakeholders have a common high level of knowledge about the organization and are therefore able to effectively coordinate each other before or during actual projects. 6 Reflection and outlook In this paper, we analyzed top-down driven methods for EA transformation planning as well as bottom-up driven methods for requirements, release, and synchronization management. We integrated design activities and techniques used in these domains into a method for an integrated EA planning. Our method description focuses on the coordination of distributed planning activities and an underlying information model, which provides the modeling concepts for addressing requirements (R1), (R3), and (R6). 34 Building on the contained information about the transformation and evolution plans, the delineated method and techniques particularly aim at requirements (R4) and (R9). The applicability of method and information models has finally been demonstrated with an industry case. However, there still are a number of questions that we have not answered yet but given an indication in the case only. For example our approach does not generally describe how exactly configuration mechanisms for systems of intermeshed closed-loop control systems work and whether there may be a (limited) number of reference configurations for an integrated EA planning Also criteria for determining the number of iterations for global and local planning cycles are unknown. It is further unknown, which exit conditions are valid, i.e. when to stop the EA planning phase and proceed with refinements and implementations. Finally, it has to be shown that there is a business case for such a “coordinated” approach of an integrated EA planning opposed to an even more decentralized and less coordinated development plan. However, in practice we observe a growing demand and acceptance for such a coordinated planning. This is because alternatively a coordination of projects applying for funding is often performed by prioritization and projects are postponed after available budgets are assigned. The prioritization process, taking only the financial dimension into account, however, often results in dysfunctional plans. Bibliography [AG10a] Aier, S.; Gleichauf, B.: Applying design research artifacts for building design research artifacts: A process model for enterprise architecture planning. In (Winter, R.; Zhao, J.L.; Aier, S.): (eds.) Global Perspectives on Design Science Research, 5th International Conference, DESRIST 2010, Springer, 2010; pp. 333-348. [AG10b] Aier, S.; Gleichauf, B: Towards a systematic approach for capturing dynamic transformation in enterprise models. In HICSS, 2010; pp. 1-10. [AW90] Antill, J.; Woodhead, R.: Critical path methods in construction practice. WileyInterscience, 1990. [Br05] Braun, C.; Wortmann, F.; Hafner, M.; Winter, R.: Method construction - a core approach to organizational engineering. In SAC, 2005; pp. 1295-1299. [Bu09] Buckl, S.; Ernst, A.M.; Matthes, F.; Schweda, C.M.: An information model for managed application landscape evolution. Journal of Enterprise Architecture (JEA) 5(1), 2009; pp. 12-26. [CA70] Conant, R.C.; Ashby, W.R.: Every good regulator of a system must be a model of that system. Intl. J. Systems Science, 1970; pp. 89-97. [CEF99] Carlson, A.; Estepp, S.; Fowler, M.: Temporal patterns. In Pattern Languages of Program Design. Addison Wesley, Boston, MA, USA, 1999. [ES10] Ernst, A.M.; Schneider, A.W.: Roadmaps for enterprise architecture evolution. In Engels, G.; Luckey, M.; Pretschner, A.; Reussner, R.: (eds.) 2nd EuropeanWorkshop on Patterns for Enterprise Architecture Management (PEAM2010) Paderborn, Germany, 2010; pp. 253-266. [Gu94] Gutzwiller, T.A.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen. Ph.D. thesis, Universität St.Gallen, 1994. 35 [HG94] Hahn, D.; Grünewald, H.: PuK, Controllingkonzepte: Planung und Kontrolle, Planungsund Kontrollsysteme, Planungs-und Kontrollrechnung. Gabler, 1994. [HV93] Henderson, J.C.; Venkatraman, N.: Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal 32(1), 1993; pp. 472-484. [HW03] van der Hoek, A.; Wolf, A.L.: Software release management for component-based software. SOFTWARE-PRACTICE AND EXPERIENCE 33(1), 2003; pp. 77-98. [IOS07] International Organization for Standardization.: ISO/IEC 42010:2007 Systems and software engineering - Recommended practice for architectural description of softwareintensive systems, 2007. [Ke09] Kerzner, H.: Project management: a systems approach to planning, scheduling, and controlling. Wiley, 2009. [LLO93] Luftman, J.N.; Lewis, P.R.; Oldach, S.H.: Transforming the enterprise: The alignment of business and information technology strategies. IBM Systems Journal 32(1), 1993; pp. 198-221. [MS95] March, S.; Smith, G.: Design and natural science research on information technology. Decision Support Systems 15(4), 1995; pp. 251-266. [Ma08] Matthes, F.; Buckl, S.; Leitel, J.; Schweda, C.M.: Enterprise Architecture Management Tool Survey 2008. Chair for Informatics 19 (sebis), Technische Universität München, Munich, Germany, 2008. [OGC00] Office of Government Commerce (OGC).: ITIL - Service Delivery. IT Infrastructure Library (ITIL), The Stationery Office, Norwich, UK, 2000. [PMI00] Project Management Institute.: A Guide to the Project Management Body of Knowledge, 2000. [Pe07] Peffers, K.; Tuunanen, T.; Rothenberger, M.; Chatterjee, S.: A design science research methodology for information systems research. Journal of Management Information Systems 24(3), 2007; pp. 45-77. [Pu06] Pulkkinen, M.: Systemic management of architectural decisions in enterprise architecture planning. four dimensions and three abstraction levels. In: Proceedings of the 39th Annual Hawaii International Conference on System Sciences, 2006; pp. 179c. [RWR06]Ross, J.W.; Weill, P.; Robertson, D.C.: Enterprise Architecture as Strategy. Harvard Business School Press, Boston, MA, USA, 2006. [So01] Sommerville, I.: Software Engineering. Pearson Studium, Munich, Germany, 6th edn., 2001. [Wa05] Wagter, R.; van den Berg, M.; Luijpers, J.; van Steenbergen, M.: Dynamic Enterprise Architecture: How to Make IT Work. John Wiley, 2005. [Wi08] Winter, R.: Business engineering - betriebswirtschaftliche konstruktionslehre und ihre anwendung in der informationslogistik. In: Integrierte Informationslogistik. Springer, Berlin, Heidelberg, Germany, 2008; pp. 17-38. 36 Applying Soft Systems Methodology in Enterprise Architecture Creation Workshops Agnes Nakakawa1 , Patrick van Bommel 1 , H.A. Erik Proper1,2 1 ICIS, Radboud University Nijmegen P.O. BOX 9010, 6500 GL Nijmegen, The Netherlands. 2 CRP Henri Tudor, L-1855 Luxembourg-Kirchberg, Luxembourg. A.Nakakawa@science.ru.nl, pvb@cs.ru.nl, Erik.Proper@tudor.lu Abstract: Lack of effective involvement of stakeholders is one of the main drawbacks of enterprise architecture initiatives. Ongoing attempts to overcome this involve using Collaboration Engineering to develop a collaboration process that enterprise architects can execute to facilitate collaborative sessions with stakeholders during architecture creation. However, a field study evaluation of this process revealed that it offered inadequate support for stirring vigorous and rigorous discussions during activities that required organizing and assessing problem or solution aspects that resulted from brainstorming activities. Since Soft Systems Methodology (SSM) helps to structure rational thinking about messy situations, its techniques can be adapted to supplement the design of the collaboration process with support for triggering discussions and creating a shared understanding and vision among stakeholders. This paper therefore presents a script that shows how this can be done, and discusses its evaluation in a real case. 1 Introduction The common drawbacks of enterprise architecture development include the lack of: effective involvement of stakeholders; support and commitment from top management; effective communication; and a mutual understanding of the purpose of the architecture effort [Ben05, Gar09, Sta95]. Enterprise architects have reported various challenges that hinder effective stakeholder involvement during architecture creation (see [NBP10]). The challenges are mainly caused by two issues. First, the success of collaborative sessions that involve enterprise architects and stakeholders mainly depends on the presence of a professional (or skilled) facilitator. Second, there is lack of a clear, predictable, and repeatable way of managing tasks that require effective stakeholder involvement. Ongoing attempts to overcome these issues involve using Collaboration Engineering to develop a collaborative process that enterprise architects can execute (by themselves) so as to manage tasks that require effective collaboration with stakeholders during enterprise architecture creation. Collaboration Engineering was chosen because it offers affordable facilitation to practitioners (in this case enterprise architects) of recurring high-value tasks (like enterprise architecture creation), by enabling the development of repeatable processes that 37 practitioners can execute without hiring a professional facilitator [BVN03, VB05]. According to [KV07, VB05], a collaborative process for a given task is designed using the following procedure: specifying the goal and deliverables of the process; defining the activities that participants must execute so as to achieve the goal; specifying the reasoning phases participants must undergo in order to achieve the goal; and describing detailed facilitation support for each activity. Facilitation support is specified by articulating: (a) the Group Support System (GSS) tools that should be used (or alternative techniques) during the collaborative sessions; (b) how the tools should be configured; and (c) the message prompts that should be followed [BVN03]. This design approach was adapted when formulating the collaboration process for effectively involving stakeholders during enterprise architecture creation. This process is herein referred to as Collaborative Evaluation of Enterprise Architecture Design Alternatives (CEADA). The earlier version of CEADA was evaluated in a field study (of five organizations) where it was effective in supporting activities that required stakeholders to brainstorm, prioritize or rank or rate concerns and requirements for the architecture; and perform multi-criteria evaluation of possible enterprise architecture design alternatives. However, CEADA was still lacking adequate support for stirring vigorous and rigorous discussions when executing activities that required stakeholders and architects to reduce and organize aspects from brainstorming activities; and assess possible interrelationships and implications. This was reflected in the feedback (see section 2) from stakeholders who participated in the sessions supported by CEADA; the facilitator; and the observer of the sessions. Since the main focus of this research is to offer effective stakeholder involvement in architecture creation, in this paper we propose to address the above weakness by supplementing CEADA with techniques for enhancing the creation of a shared understanding and vision during execution of activities that involve organizing and discussing brainstormed aspects. We focus on adapting Soft Systems Methodology (SSM) because of its reputation for managing complex and ill-structured organizational problems through structuring rational thinking about them [Che98]. We also adapt the cause-effect analysis diagram (or Fishbone or Ishikawa) technique because of its support for thorough problem analysis [Ish86]. Since SSM offers implicit facilitation support for collaborative workshops or discussion debates among problem owners and solver(s), Collaboration Engineering is further used in designing the facilitation script that shows how SSM and Ishikawa techniques can be used in enterprise architecture creation. For the remaining part of this paper, Section 2 presents the research methodology; Section 3 discusses the script that extends CEADA to address its weaknesses; Section 4 presents the evaluation results of CEADA’s performance in a real organization; and Section 5 concludes the paper. 2 Research Methodology This research adapts the Design Science methodology. In Design Science, significant organizational problems are solved by: designing suitable artifacts using knowledge derived from scientific theories and industrial experiences; evaluating those artifacts using experiment and real life environments; and refining the artifacts to address their inefficiencies 38 [BVN03]. In this research CEADA is the ultimate artifact, which was designed based on literature from the enterprise architecture development realm, collaborative problem solving and decision making realm, and expert advice from enterprise architects and professional facilitators. In our earlier work[NBP11], a field study evaluation of CEADA indicated that it is already successful in effectively supporting communication during the execution of tasks that involve brainstorming and evaluating problem and solution aspects. However, evaluation feedback also indicated the need to enhance CEADA’s support for tasks that require stakeholders to filter, clarify, organize, and discuss problem and solution aspects that arise from a brainstorming activity. This is implied by the following three issues highlighted in the feedback from the field study. First, more time in the sessions was spent seeking a shared understanding and shared vision of problem and solution aspects, and yet some stakeholders complained (at the end of the sessions) that they had less discussion time. Second, stakeholders suggested that using (simple) visual representations of their ideas (prior to discussing and evaluating the architecture models) would have helped them to better analyze and understand the problem and solution aspects and the architecture models. Third, the participation of stakeholders decreased during activities that involved organizing and discussing problem and solution aspects. This could have been caused by the less hands-on nature of the way the organize tasks were executed. These three issues indicate the need to devise a way that will improve the execution of CEADA activities that require explicit articulation, proper organization, and thorough discussion of the problem and solution aspects. Such activities require stakeholders and architects to undergo the reduce, clarify, and organize patterns of reasoning 1 . However, Collaboration Engineering research has widely addressed issues encountered in the other patterns of reasoning (i.e. generate, evaluate, and build consensus), but more research is needed in addressing issues encountered in the reduce, clarify, and organize patterns of reasoning such that the effectiveness of collaboration processes can be improved [VB05]. Therefore, this paper reports work on an extended version of CEADA that attempts to address the above issues by triggering purposeful discussions that help stakeholders to acquire a shared understanding of problem and solution aspects during enterprise architecture creation workshops. The extended CEADA comprises of a script designed by adapting knowledge from SSM, the Ishikawa diagram technique, and Collaboration Engineering. Thereby, the weaknesses of any of these methods in effectively supporting execution of activities in architecture creation workshops, are overcome by the strengths of the other methods. The extended CEADA has been evaluated in a real organization and findings are discussed in section 4. 1 According to [BVN03, BVN+ 06], there are six patterns of reasoning that a group may undergo, i.e.: generate, moving from a state of having few to more concepts through brainstorming; reduce, moving from a state of having many to few concepts that are worthy of further attention; clarify, moving from a state of having less to more shared understanding and meaning of concepts; organize, moving from a state of having less to more understanding of the relationships among concepts under consideration; evaluate, moving from a state of having less to more understanding of the value of concepts under consideration; and build consensus, moving from a state of having fewer to more group members agree and commit to proposed concepts. 39 3 Soft Systems Methodology in Architecture Creation This section discusses the adaptation of SSM and Ishikawa diagram techniques to improve CEADA. In addition, the usability of the CEADA script has been demonstrated using scenarios from one of the organizations in which CEADA was earlier evaluated, i.e. Wakiso District Local Government (WDLG). WDLG is an administrative and service delivery organization that operates under the Ministry of Local Government in Uganda; and consists of 11 departments, each having a number of subsections [Wak08]. Baseline (as-is) enterprise architecture models Use to formulate - Rich Picture - Analysis One Two Three Represent in form of - Root definitions - CATWOE analysis - Conceptual models Use to formulate Represent in form of 1. Study the organization’s problem situation 4. Take action to improve problem situation 2. Formulate purposeful activity models describing the desired situation Target (to-be) enterprise architecture models 3. Compare models with real world views Debate about desirable & feasible changes Use to refine Find accommodations between conflicting interests Figure 1: Adaptation of SSM in Enterprise Architecture Creation (Based on [Che98]) According to [Che98], SSM mainly comprises of the following four stages. Stage one involves studying the problem situation and representing it using: (a) Rich Picture – a holistic expression of aspects that describe the problem situation e.g. processes, actors and their thoughts or concerns; and (b) Analysis One Two Three – a description of all problem owners, cultural or social aspects (i.e. roles or norms or values), and political aspects of the problem situation. Stage two involves describing the desired situation by: (a) Formulating Root Definitions – explicit phrases that briefly describe the desired transformation in form of “what should be done”, “how it should be done”, and “why it should be done”; (b) Performing a CATWOE analysis of each Root Definition – assessing Customers who will be affected by the transformation, Actors who will implement the transformation, Transformation process(es) that will be affected, World views regarding the transformation, Owner(s) of the transformation, and Environmental and external issues that will affect the transformation; (c) Using the Root Definitions and their CATWOE analysis to assemble all proposed transformation processes into conceptual or purposeful activity models that describe the desired situation. Stage three involves comparing the conceptual models with real world views through holding debates which aim at: (a) defining desirable and feasible changes for improving the problem situation; (b) finding accommodations between conflicting interests regarding the problem situation and the desired changes. Stage four involves taking appropriate action to address the problem situation. The adaptation of the SSM techniques defined in stages one to three into enterprise architecture creation workshops is shown in Figure 1. From figure 1, Rich Picture and Analysis One Two Three can be adapted as techniques for gathering information for formulating baseline architecture models (see section 3.1), whereas Root Definitions, CATWOE anal- 40 1. Communicate purpose of session 1 Tool Name: Manual Step Name: [Activity 1.0] Facilitator Notes: Purpose of session is to gather information on the organization’s problem & solution aspects 2. Define services offered by, & processes executed in, the organization Tool Name: Generate Step Name: [Activity 1.1.1] Outline File Name: GenOrgnProcesses.mw Step Specific Information: Allow unlimited No. of items per topic; viewing other participant input; & participants to control topic selection. This configuration applies to all activities supported by the generate tool in this script. Topic List: (1) What are the services offered by, & the processes executed in, this organization? (2) What are the organization’s information inflows? (3) What are the organization’s information outflows? (4) Who are the external partners of this organization (e.g. unions, consortiums, sponsors, etc), & which departments do they collaborate with? (5) What are the completed & ongoing projects in the organization? Facilitator Notes: Explain the data capturing functions (or answering formats) for each question to participants, i.e.: (1) {Department}-{services it offers}-{Processes it executes to offer its services}; (2) {type of information inflow}-{information sender}; (3) {type of information outflow}-{information recipient}; (4) {Department}-{External partner(s)}; (5) {project name}-{project status}-{where to find documentation about the project} 3. Clarify & organize attributes of processes in the organization Tool Name: Organize Step Name: [Activity 1.1.1.1] Output File Name: OgzdProcesses.mw Step Specific Information: Input file - [GenOrgnProcesses.mw]; Step will run in Outliner Mode. Facilitator Notes: Display the generated list of processes & invoke a specialization-driven-division (i.e. divide stakeholders into small groups based on their departments/specialization). This enables detailed assessment of the as-is situation & enhances communication, shared understanding, & homogeneity in a subgroup. Guide each subgroup to do the following: (1) Clean & clarify items in the processes list under their department (2) Distribute copies of the Ishikawa diagram template for capturing process attributes to all subgroups. Guide them to fill in the required prompts in the template, using the cleaned list of processes in their department. (3) Display key symbols you have chosen for drawing a Rich Picture. Guide each subgroup to draw a Rich Picture of the as-is situation of its department, showing the actors, their roles, their concerns etc. (4) Converge subgroups & encourage representatives of each subgroup to discuss their department-specific Ishikawa diagrams for processes; & department-specific Rich Picture. To help the group to acquire a shared understanding of the as-is situation, map all the department-specific Ishikawa diagrams for processes onto an organization-wide Ishikawa diagram for processes; & merge all the department-specific Rich Pictures to form an organization-wide Rich Picture. Plug these diagrams on to the holistic data capture template. 4. Define the challenges or problems faced in the organization Tool Name: Generate Step Name: [Activity 1.1.2] Outline File Name: GenOrgnChallenges.mw Topic List: What are the challenges or problems faced in this organization? Facilitator Notes: Explain the answering format: {Department}-{challenges faced by the department} 5. Determine the root problem cause Tool Name: Organize Step Name: [Activity 1.1.3] Output File Name: OrgnRootProblemCauses.mw Step Specific Information: Input file - [GenOrgnChallenges.mw]; Step will run in Outliner Mode. Facilitator Notes: Display the generated list of challenges, & invoke a specialization-driven-division (this is explained in activity 1.1.1.1). Guide each subgroup to do the following: (1) Clean & clarify items in the challenges list under their department (2) Distribute copies of the Ishikawa diagram template for problem analysis to all subgroups. Guide them to perform a cause-effect analysis of problems in their department, by filling the required prompts in the template. The department-specific Rich Pictures from activity 1.1.1.1 can be used as a source of information. (3) Converge subgroups & encourage representatives of each to discuss their department-specific Ishikawa diagrams for problem analysis & the identified root problem cause(s). Clean & organize the challenges list using output from the subgroups. Map all the department-specific Ishikawa diagrams for problem analysis onto an organization-wide Ishikawa diagram for problem analysis, & identify the general root problem cause(s). 6. Identify un-captured problem aspects & any anomalies in the output of problem analysis Tool Name: Generate Step Name: [Activity 1.1.4] Outline File Name: CommentsOnProblemAnalysis.mw Topic List: (1) What concerns do you have about any of the Ishikawa diagrams for problem analysis? (2) Which effects & causes of problems (or organizational weaknesses & threats) have not been represented? Facilitator Notes: Explain answering format: {Department}-{cause/effect/weakness/threat} Figure 2: Facilitation Script for adapting SSM in Architecture Creation ysis, and activity models can be adapted as techniques for gathering information for formulating target architecture models (see section 3.2). 3.1 Creating Baseline Enterprise Architecture Models SSM is a structured inquiry process which uses models as a source of questions about a problem situation [Che98]. This section presents five structured and question-triggering techniques that can be used in interviews and group sessions (or when reviewing organization documentation) to gather information for creating baseline architecture models. These include: (a) the Ishikawa diagram, a technique useful for assessing problems and their causes [Ish86]; (b) Rich Picture, and Analysis One Two Three [Che98] (these tech- 41 7. Assess Amendments to the problem analysis outcome Tool Name: Organize Step Name: [Activity 1.1.5] Output File Name: AdditionsProblemAnalysis.mw Step Specific Information: Input file - [CommentsOnProblemAnalysis.mw]; Step will run in Outliner Mode. 8. Seek consensus on outcomes of problem analysis Tool Name: Evaluate Step Name: [Activity 1.1.6] Output File Name: ConsensusProblemAnalysis.mw Step Specific Information: Input Topic List Items - [Yes, I agree with the problem analysis results; No, I do not agree with the problem analysis results]; Evaluation Method - [Vote (Yes/No)]; Display Variability - [Yes]. Facilitator Notes: Encourage participants who do not agree to attach comments on their votes. Discuss the comments & re-vote to enable participants to reach a realistic level of shared understanding of problem aspects 9. Define aspects that describe the organization’s problem scope Tool Name: Generate Step Name: [Activity 1.1.7] Outline File Name: GenAspectsProblemScope.mw Topic List: (1) Which processes or stakeholders (i.e. current problem owners) are affected by the problems? (2) Which processes or stakeholders (i.e. possible problem owners) are likely to be affected by the problems? Facilitator Notes: The filled Ishikawa diagram for problem analysis can be used as a source of information. 10. Clarify & organize the generated aspects on the problem scope Tool Name: Organize Step Name: [Activity 1.1.8] Output File Name: OgzdAspectsProblemScope.mw Step Specific Information: Input file - [GenAspectsProblemScope.mw]; Step will run in Outliner Mode. 11. Evaluate & agree on aspects that define the organization’s problem scope Tool Name: Evaluate Step Name: [Activity 1.1.9] Output File Name: AgreedProblemScope.mw Step Specific Information: Input topic file - [OgzdAspectsProblemScope.mw]; Evaluation Method - [Select (Mark all that apply)]; Display Variability - [Yes] 12. Reaffirm key organization principles associated with problem aspects Tool Name: Generate Step Name: [Activity 1.2.0] Outline File Name: AssociatedOrgnPrinciples.mw Topic List: (1) Which business (& architecture principles, if they exist) are associated with the problems the organization is facing or with any possible solutions to the problems? (2) What are the accepted practices in the organisation? (3) What are the existing management or governance frameworks in this organisation? Facilitator Notes: answering format is: {name of principle/practice/framework} - {source of information about it} 13. Specify business strategy & goals Tool Name: Generate Step Name: [Activity 1.3.0] Outline File Name: GenBusinessStrategyGoals.mw Topic List: Which business strategy & goals does the organization have so as to overcome its problems? Facilitator Notes: Explain the answering format: {strategy: goals}. If the business strategy & goals are already documented, provide a seed file listing them & prompt participants to give their views about the strategy & goals. 14. Clarify & validate the business strategy & goals Tool Name: Organize Step Name: [Activity 1.3.1] Output File Name: OgzdBusinessStrategyGoals.mw Step Specific Information: Input file - [GenBusinessStrategyGoals.mw]; Step will run in Outliner Mode. Facilitator Notes: Categorize business goals according to the business strategy that are intended to achieve. Plug results into the right section in the holistic data capture pyramid or template. 15. Evaluate & agree on the business strategy & goals Tool Name: Evaluate Step Name: [Activity 1.3.2] Output File Name: RankBusinesStrategyGoals.mw Step Specific Information: Input topic file - [OgzdBusinessStrategyGoals.mw]; Evaluation Method:[Rank from 1 to N (Use each value only once)]; Display Variability: [Yes] Facilitator Notes: Prompt stakeholders to prioritize or rank the business goals. 16. Determine possible business solution alternatives for achieving the strategy & goals Tool Name: Generate Step Name: [Activity 1.4.0] Outline File Name: GenBusinessSolnAlternatives.mw Topic List: What can the organization do in order achieve its business strategy & goals? 17. Clarify & organize the generated business solution alternatives Tool Name: Organize Step Name: [Activity 1.4.1] Output File Name: OgzdBusinessSolnAlternatives.mw Step Specific Information: Input file - [GenBusinessSolutionAlternatives.mw]; Step will run in Outliner Mode. Facilitator Notes: Guide stakeholders to: identify which business solution alternatives can be treated as specifications of a given solution alternative; & assess each solution alternative by filling in the required prompts in the Ishikawa diagram template for capturing constraints of a given business solution alternative. Figure 3: Facilitation Script for adapting SSM in Architecture Creation (Contd.) niques are defined in the preceding section); (c) short data capture statements or functions; and (d) a holistic data capture pyramid template, which has been formulated based on literature in [Lan05, OPW+ 08] to give an overview of all aspects to be addressed during enterprise architecture creation. The CEADA script in figures 2, 3, 10, and 11 shows when and how to apply these techniques during group sessions with client stakeholders. It has been formulated based on the procedure for designing collaborative processes (see section 1), and it has been documented using MeetingworksTM GSS. The detailed procedure of how the activities in CEADA were derived was discussed in our earlier work (see [NBP11]), the script herein extends CEADA by offering execution details of its activities. In figure 2 the facilitation notes of activity 1.0 introduce the holistic data capture pyramid template (see figure 4), which provides a shared holistic view and shared understanding of data that is to be gathered during architecture creation and all the information templates that are to be used. In addition, the facilitation notes in figure 2 (activities 1.1.1.1 and 1.1.3), figure 3 (activity 1.4.1), and figure 11 (activity 4.2) show how the Ishikawa dia- 42 Mission Vision Values Strategy Principles Culture External Goals regulations Ishikawa for Constraints Actions to achieve the goals (Ak) Enterprise architecture Ishikawa for attributes of processes in as-is state Ishikawa for Requirements Domain/unit architectures for to-be state Domain/unit architectures for as-is state Ishikawa for attributes of processes in to-be state Problem analysis Ishikawa Current Rich Pictures Operations (processes, products, people, or as-is Desired or to-be Figure 4: Holistic Data Capture Pyramid Template (Based on [Lan05, OPW+ 08]) Beneficiaries Outflows(Results) Inflows (Inputs) Organization or department process Internal Actors External Actors Figure 5: Adapted Ishikawa Diagram Template for Capturing Process Attributes gram technique has been adapted in mainly four ways. These include: Ishikawa diagram template for capturing attributes of processes executed in an organization (see figure 5); Ishikawa diagram template for analyzing the problematic aspects in an organization (see figure 6 for the problem analysis template that was used at WDLG); and Ishikawa diagram templates for defining constraints and requirements that the architecture pertaining to a given (business) solution alternative must fulfill (see figure 8). The facilitation notes in the script also indicate that once these templates are populated with data, they can be plugged into the holistic data capture pyramid template in figure 4. Furthermore, in figure 2 (activity 1.1.1.1), facilitator notes also introduce the use of a Rich Picture in capturing baseline operations of departments in an organization. From figure 7, there are six key symbols that can be used to formulate a Rich Picture. As shown in figure 7, these symbols were used to formulate a Rich Picture for the as-is situation at WDLG. It shows that WDLG involves various complexities of people (represented with a face-like symbol and accompanying text) e.g. departments, committees, community. The level of detail in a Rich Picture depends on the problem solver [Che98]. Thus, to avoid an overcrowded Rich Picture and to enable shared understanding about the major problem(s) faced, the subsections in each of the 11 departments have not been represented. The dotted lines represent twoway communication, and the storage symbol on a dotted line indicates a decentralized way of data storage. The un-dotted lines represent responsibilities of a given group of people, the stars represent the services offered, and the cloud call-out represents problems faced. 43 Cause of the problem (CkPkSkDi) Problem faced by the department subsection (PkSkDi) Department (Di (for i=1,2, ,11) Department subsection (SkDi) WDLG Figure 6: Adapted Ishikawa Diagram Template for Problem Analysis in WDLG As the script indicates in figure 2 (activity 1.1.1.1), these symbols can be used to draw department-specific Rich Pictures, which can later be merged into an organization-wide Rich Picture. 3.2 Creating Target Enterprise Architecture Models The script in figure 3 (activity 1.4.1) and figure 11 (activity 4.2) describe when and how to use the adapted Ishikawa template for gathering data on constraints and requirements that the architecture must address (see figure 8). In addition, in figure 10 (activity 1.6.1) the script describes when and how to articulate the purpose of the architecture creation initiative using the architecture purpose template shown in figure 9. Furthermore, the script in figure 11 (activity 4.1) shows when and how to use SSM’s Root Definitions and CATWOE analysis to gather information on requirements and solution scenarios that must be represented in the target architecture models. For example, one of the Root Definitions for WDLG can be denoted as (R), where: R = {What to do – enable centralized data storage and IT-supported data processing and sharing in WDLG}; {How to do it – by purchasing database servers and client computers, and setting up and maintaining a Local Area Network}; {Why do it – in order to have consistent data records, realtime data retrieval, and improved service delivery in WDLG}. Consequently, the CATWOE analysis of R is as follows: Customers {WDLG staff, Wakiso district community}; Actors {staff in the IT section of the planning department of WDLG, ICT and Internet service providers}; Transformation process {input – isolated databases and manual departmentspecific processes, output – centralized database and IT-supported departmental but coherent processes}; World views {centralized database system yields consistent data records and enhances data sharing}; Owners {Technical Planning Committee, Ministry of Local Government}; and Environmental or external issues {financial resources from the Ministry}. Furthermore, the script in figure 11 (activity 4.2.2) shows that requirements can be thoroughly elaborated using the Requirements Elaboration Template (see figure 12). This template shows how the above CATWOE aspects of SSM can be used to assess the requirements that the architecture must address. Figure 12 shows that activity models can be used to represent the transformation processes that must be implemented or executed 44 We lack: IT enabled information processing, centralized information storage, real time information retrieval, & data sharing Ministry of Local Government Technical Planning Committee Create Community welfare services e.g. governing laws, tax collection, water, roads, buildings, financial management, etc Statutory bodies District 3-year Development Plan Prepare & Oversee implementation of Registry Provide Planning Provide Natural resources Finance Provide Provide CAO Education Internal audit Health Build Works Production & marketing Provide Community welfare services e.g. schools, hospitals, farms, land use planning, environmental preservation etc Create Create Community based development Create Lower Local Governments Make use of Make use of Development programs Make use of Community Community Figure 7: Rich Picture For WDLG as-is Situation so as to achieve a given requirement. Figure 12 is an adaptation of the format of activity models provided by [HWP99]. 4 Performance Evaluation of the CEADA Script The CEADA extension script presented in section 3 was evaluated in the Department of Radiotherapy at Mulago Hospital in Uganda. This department is concerned with: the treatment of cancer; training of radiography students of the Makerere University College of Health Sciences; undertaking research on cancer treatment; and sensitizing the public about cancer issues. Out of the 20 staff members in the department, about 14 participated in the CEADA evaluation. The aim of CEADA in this case was to guide the collaborative creation of an enterprise architecture that would improve the execution of operational processes in the radiotherapy department. The execution of the CEADA script was done using interviews and a collaborative session. Output from interviews was first analyzed and it was then used to formulate the preliminary models that were discussed in the collaborative session. Due to the busy schedule of the department (given its various patients), only one collaborative session was conducted, in which all activities were executed. Thereafter, members who attended the session were 45 External Constraints ?? Why should it be done? ?? Internal Constraints ?? ?? ?? ?? ?? How should it be done? ?? ?? ?? ?? Solution Alternative (SAp) What should be done? ?? Architecture Requirements of the Chosen Solution Alternative ?? ?? High Level Solution Specifications Figure 8: Adapted Ishikawa Diagram Template for Constraints and Requirements To support decision making regarding the desired transformation To show the impact of the desired transformation Purpose of Enterprise Architecture To specify business To inform & contract requirements service providers Figure 9: Diagram Template for Purpose of the Architecture Initiative (Based on [OPW+ 08]) given questionnaires so as to capture their evaluation of the performance of the CEADA script against a number of quality criteria. Table 1 presents the evaluation results. Column 2 of table 1 shows the evaluation criteria that were used. These criteria are discussed in detail in [NBP11]. The scores used to measure CEADA’s performance were based on a 5-point Likert scale, as shown in the last row of table 1. The mean score of CEADA’s performance under each criterion (or sub criterion) is shown in table 1. The standard deviation of the scores (as shown in table 1) illustrates the degree of variability among stakeholders regarding CEADA’s scores under each criterion. The mean scores in table 1 indicate that CEADA’s performance was good regarding the support for creating a shared understanding and shared vision among stakeholders. In addition, the low standard deviations of scores (shown in the last column of table 1), implies that there was generally a high level Table 1: Performance Evaluation Results of the CEADA Script # Evaluation Criteria for Measuring Performance of the CEADA Script Performance Indicator Mean score Standard deviation of scores 4.36 0.50 1 Support for creating a shared understanding (among stakeholders) of the problem and solution aspects of the organization a Support for enabling stakeholders to understand why some of their 4.15 0.55 concerns/views would not apply in some contexts b Support for enabling stakeholders to understand the concerns of other 4.36 0.84 stakeholders about the current and future operations in the organization c Support for enabling stakeholders to understand the results of the architecture 4.25 0.45 process 2 Support for enabling stakeholders to freely express their views about the current 4.43 0.94 operations in the organisation 3 Support for attaining stakeholders’ satisfaction with the activities done in the 4.50 0.52 collaborative session(s) 4 Support for attaining stakeholders’ satisfaction with the outcome(s) of the 4.23 0.60 collaborative session(s) a Support for enabling constructive critiquing of ideas generated in the session(s) 1.50 0.52 b Support for enabling stakeholders to understand the objectives of the session(s) 4.29 0.61 Note: The evaluation scale used in the questionnaire that evaluated CEADA sessions is a 5 point Likert scale with responses ranging from strongly disagree (point 1) to strongly agree (point 5) 46 18. Choose appropriate business solution alternative Tool Name: MultiCriteria Step Name: [Activity 1.4.2] Output File Name: ChosenSolnAlternative.mw Step Specific Information: List of Alternatives - [OgzdBusinessSolnAlternatives.mw]; Input Criteria List Items [Suitability with respect to: (1) satisfying organization principles i.e. internal constraints; (2) achieving business strategy; (3) achieving business goals; and (4) satisfying external regulations or constraints] Facilitator Notes: Prompt stakeholders to comment on their scores of the business solution alternatives. 19. Define external constraints that should be considered during enterprise architecture effort Tool Name: Generate Step Name: [Activity 1.5.0] Outline File Name: GenExternalConstraints.mw Topic List: (1) What are the policies or laws from regulatory authorities (& what do they imply) that relate to the defined solution aspects? (2) What are the policies or laws from the organization's consortiums, donors or sponsors, unions etc, that relate to the defined solution aspects? Facilitator notes: Explain answering format: {name of body} - {external principle} - {implied external constraint} 20. Clarify & organize the identified external constraints Tool Name: Organize Step Name: [Activity 1.5.1] Output File Name: OgzdExternalConstraints.mw Step Specific Information: Input file - [GenExternalConstraints.mw]; Step will run in Outliner Mode. Facilitator notes: Plug results into the right section in the holistic data capture pyramid or template. 21. Define the purpose of the enterprise architecture effort Tool Name: Generate Step Name: [Activity 1.6.0] Outline File Name: GenPurposeEAEffort.mw Topic List: (1) What is the main issue that the enterprise architecture effort must address in order to achieve the defined solution aspects? (2) In realizing the desired solution aspects, how do you want to use the resultant enterprise architecture? 22. Clarify & organize aspects regarding the purpose of the architecture effort Tool Name: Organize Step Name: [Activity 1.6.1] Output File Name: OgzdAspectsPurposeEAEffort.mw Step Specific Information: Input file - [GenPurposeArchitectureEffort.mw]; Step will run in Outliner Mode. Facilitator notes: Guide participants to classify their ideas about the purpose of the architecture into 4 major categories (which are adaptation of the general uses of enterprise architecture defined in Op ‘t Land et al (2008)), i.e. enterprise architecture will be used for: (a) supporting decision making regarding the chosen business solution alternative; (b) showing the impact of the business strategy and the chosen business solution alternative; (c) specifying business requirements; (d) informing & contracting service providers. 23. Agree on the general purpose of the enterprise architecture effort Tool Name: Evaluate Step Name: [Activity 1.6.2] Output File Name: AgreedPurposeArchEffort.mw Step Specific Information: Input topic file - [OgzdAspectsPurposeEAEffort.mw]; Evaluation Method - [Select (Mark all that apply)]; Display Variability - [Yes] 24. Define high level solution specifications & scope of the enterprise architecture effort Tool Name: Generate Step Name: [Activity 1.7.0] Outline File Name: GenSolnSpecsScope.mw Topic List: (1) Which business services, functions, departments or areas of the organisation should the architecture creation effort focus on? (2) Which of the existing business functions should not be considered in the desired state? (3) Which architecture domains (i.e. business, data, applications, & technology) should be covered during architecture creation? (4) What is the desired level of detail that the architecture creation effort should focus on? (5) From the completed & ongoing projects in the organization, which architectural resources are available in the organisation, and can be considered for use during architecture creation? (6) List any constraints (i.e. enterprise-wide or project-specific constraints) that the organization principles impose on the implementation of the defined business strategy or chosen business solution alternative 25. Clarify & assess the defined high level solution specifications or architecture scope dimensions Tool Name: Organize Step Name: [Activity 1.7.1] Output File Name: OgzdSolnSpecsScope.mw Step Specific Information: Input file: GenSolnSpecsScope.mw; Step will run in Outliner Mode. Facilitator notes: assess aspects with respect to problem scope & the purpose of architecture 26. Agree on high level solution specifications & scope of the architecture effort Tool Name: Evaluate Step Name: [Activity 1.7.2] Output File Name: AgreedSolnSpecsScope.mw Step Specific Information: Input topic file - [OgzdSolnSpecsScope.mw]; Evaluation Method - [Select (Mark all that apply)]; Display Variability: [Yes]. Plug results into the holistic data capture pyramid or template. 27. Determine all solution owners & their roles in the architecture effort Tool Name: Generate Step Name: [Activity 1.8.0] Outline File Name: GenSolutionOwners.mw Topic List: List all stakeholders who will be affected by, or benefit from, or participate in the implementation of, the desired solution; & mention what the role of that stakeholder will be in the enterprise architecture effort. Facilitator Notes: Answering format: {problem/solution owner} - {Role in the architecture development effort} Figure 10: Facilitation Script for adapting SSM in Architecture Creation (Contd.) of consensus (among stakeholders) on the performance of CEADA under each criterion. Moreover, comparing CEADA’s performance results at the department of Radiotherapy with its performance results in field study one (see [NBP11]), the performance of CEADA regarding the support for creating a shared understanding and shared vision among stakeholders has improved. For example, in field study one, the average score of CEADA’s performance under “creating a shared understanding and shared vision among stakeholders” was 3.80. This average score has increased to 4.28 after the adaptation of SSM and Ishikawa diagram techniques into CEADA. Certainly, the difference in CEADA’s performance may also be caused by other factors such as the variation in the complexity and scope of the organization’s problem and solution aspects, or in the type or personalities of stakeholders dealt with. However, stakeholders’ evaluation highlighted that the Rich Picture model gives a general view of operations in an organization but lacks detailed information about how the operational processes are executed and their attributes. It was also acknowledged that the use of the Ishikawa model templates and the activity models (that are represented in form of a requirements elaboration template) helped to freely represent 47 28. Clarify & organize list of solution owners Tool Name: Organize Step Name: [Activity 1.8.1] Output File Name: OgzdSolutionOwners.mw Step Specific Information: Input file - [GenSolutionOwners.mw]; Step will run in Outliner Mode. 29. Determine all decision makers in the architecture process & their roles Tool Name: Generate Step Name: [Activity 1.9.0] Outline File Name: DecisionMakersRoles.mw Topic List: Who are the key decision makers in the organization? Facilitation notes: Answering format: {position in the organization} - {decision making responsibility} End of session 1 & preparations for session 2 30. Communicate purpose of session 2 Tool Name: Manual Step Name: [3.0] Facilitator Notes: Give a recap of results from session 1 31. Define concerns regarding problem & solution aspects from session 1 Tool Name: Generate Step Name: [3.1] Outline File Name: GenConcernsProbSoln.mw Topic List: (1) What concerns do you have regarding the problem & solution aspects?; (2) What has not been captured in the problem aspects? (3) What has not been captured in the solution aspects? (4) Which problem & solution owners have not been included? 32. Clarify & organize concerns about problem & solution aspects Tool Name: Organize Step Name: [Activity 3.2 and 3.3] Output File Name: OgzedConcernsProbSoln.mw Step Specific Information: Input file - [GenConcernsProbSoln.mw]; Step will run in Outliner Mode. Facilitator Notes: Discuss the concerns & refer to the Ishikawa diagram template for problem analysis. 33. Validate & agree on the concerns about problem & solution aspects Tool Name: Evaluate Step Name: [Activity 3.4] Output File Name: ValidConcernsProbSoln.mw Step Specific Information: Input topic file - [OgzedConcernsProbSoln.mw]; Evaluation Method - [Select (Mark all that apply)]; Display Variability - [Yes] 34. Define business requirements that the enterprise architecture must fulfill Tool Name: Generate Step Name: [Activity 4.1] Outline File Name: GenReqtsForEA.mw Topic List: To move from the current to the desired state, define WHAT should be done; HOW it should be done; & WHY it should be done. Facilitator Notes: Answering format is an adaptation of the Root Definitions of SSM, i.e.: {WHAT should be done}; {HOW it should be done}; & {WHY it should be done} 35. Clarify & organize requirements for the enterprise architecture Tool Name: Organize Step Name: [Activity 4.2] Output File Name: OgzdReqtsForEA.mw Step Specific Information: Input file: GenReqtsForEA.mw; Step will run in Outliner Mode. Facilitator Notes: Invoke a specialization-driven-division & guide stakeholders to: (1) Identify and delete all duplicate root definitions; determine which root definitions should be sub root definitions of other root definitions. (2) Fill in the prompts in the Ishikawa diagram template for capturing requirements for the architecture. Converge all subgroups & prompt stakeholders to identify any incomplete requirement (i.e. one which is not in the format of: {WHAT should be done}; {HOW it should be done}; & {WHY it should be done}. Plug results into the holistic data capture pyramid or template. 36. Elaborate requirements for the architecture using CATWOE analysis and Activity Models of SSM Tool Name: Generate Step Name: [Activity 4.2.1] Outline File Name: ElaboratedReqsForEA.mw Topic List: (1) For each requirement, who are the Customers or beneficiaries? (2) Who are the Actors responsible for realizing each requirement? (3) What are the required inputs to realize the Transformation process described in each requirement, and what are the expected outputs from the transformation process? (4) What are the World views that make each requirement meaningful or rational? (5) Who are the owners or sponsors responsible for sponsoring the realization of each requirement or stopping it? (6) What are the Environmental & external issues or constraints that may hinder the realization of each requirement? Facilitator Notes: guide the stakeholders in doing a CATWOE analysis of each agreed on root definition 37. Clarify & organize CATWOE aspects that describe the requirements & solution scenarios Tool Name: Organize Step Name: [Activity 4.2.2] Output File Name: OgzdElaboratedReqtsForEA.mw Step Specific Information: Input file - [ElaboratedReqsForEA.mw]; Step will run in Outliner Mode. Facilitator Notes: Guide stakeholders to use the Requirements Elaboration Template to clarify, organize, & verify aspects that describe the requirements & solution scenarios that the enterprise architecture must address. 38. Validate & agree on the requirements for the enterprise architecture Tool Name: Evaluate Step Name: [Activity 4.3.0] Output File Name: ValidatedReqtsForEA.mw Step Specific Information: Input topic file - [OgzdElaboratedReqtsForEA.mw]; Evaluation Method - [Rank from 1 to N (Use each value only once)]; Display Variability: [Yes] Facilitator Notes: Encourage participants to comment on the ranks they assign to requirements. Figure 11: Facilitation Script for adapting SSM in Architecture Creation (Contd.) and structure various aspects associated with the execution of the processes. Therefore, although CEADA’s improved performance may not only be attributed to the adaptation of these new techniques, the new techniques played a key role in supporting the organize and clarify patterns of reasoning. 5 Conclusions Creating an enterprise architecture in a collaborative setting (with active participation of clients) helps to create ownership and commitment among stakeholders. Thus, CEADA is being developed using Collaboration Engineering so as to provide enterprise architects with an explicit way of actively involving stakeholders during architecture creation. From the first field study evaluation of CEADA, some weaknesses were identified in its design 48 Customers or Beneficiaries or victims of requirement Xn External Factors that may affect the achievement of requirement Xn Transformation processes to be executed in order to achieve a given requirement (Xn) Process P2 ?? Process P4 Process P1 Process P5 Process P7 Process P3 Process P6 Process Pk Owners or sponsors associated with achieving requirement Xn Process P8 ?? Internal Actors that will achieve requirement Xn World view that Indicates the significance of achieving requirement Xn External Actors Figure 12: Requirements Elaboration Template that called for adaptation of SSM techniques so as to address complexities that occur in a collaborative enterprise architecture development environment. Therefore, herein CEADA has been extended using a script that adds on our earlier work by providing facilitation support for using SSM and Ishikawa diagram techniques to execute activities that require the use of clarify and organize patterns of reasoning. With the CEADA script, hands-on techniques have been adapted for each activity that requires clarifying, organizing, and discussing aspects from brainstorming tasks; and guidelines are given on how enterprise architects can use SSM and Ishikawa diagram techniques to gather data (in group sessions with clients) that can be used to create baseline and target architecture models. Although the Rich Picture has been adapted as a technique for gathering baseline information, it can also be used to gather information on the target situation. Also, embedded in the script is a questionnaire that can be used during interviews with stakeholders, or as template for gathering information from organization documentations. Thus, this research kick-starts the support for enterprise architecture data gathering and stakeholder involvement with SSM, in order to create a shared understanding and shared vision of the problem and solution aspects among organizational stakeholders. However, in line with the Design Science approach, the repeatability and predictability of the script is yet to be determined through further evaluation of CEADA. Further evaluation and refinement of the CEADA script will result in a very useful method that can be used along with the existing enterprise architecture frameworks. Acknowledgements: We are extremely grateful to staff members of the department of Radiotherapy in Mulago hospital for their participants in this research. 49 References [Ben05] Benard, S.A.: An Introduction to Enterprise Architecture - Linking Business and Technology. AuthorHouse, Indiana, 2005. [BVN03] Briggs, R.O.; Vreede, G.J. de; Nunamaker, Jr. F.: Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems. Journal of Management Information Systems, 19, 2003; pp. 31–64. [BVN+ 06] Briggs, R.O. ; Kolfschoten, G.L.; Vreede, G.J. de; Dean, D.L.: Defining Key Concepts for Collaboration Engineering. AMCIS, Acapulco, Mexico, 12, 2006. [OPW+ 08] Op ’t Land, M.; Proper, H.A.; Waage, M.; Cloo, J.; Steghuis, C.: Enterprise Architecture:Creating Value by Informed Governance. Springer Berlin, Germany, 2008. [Che98] Checkland, P.: Systems Thinking, Systems Practice. John Wiley & Sons Ltd, 1998. [Gar09] Gartner, Inc.: Gartner Identifies Ten EnterpriseArchitecture Pitfalls: Gartner Enterprise Architecture Summit 2009. http://www.gartner.com/it/page.jsp?id=1159617. Accessed on August 15th 2010. [BVN03] Hevner, A.R.; March, S.T.; Park, J.; Ram, S.: Design Science in Information Systems Research. MIS Quarterly, 28(1), 2004; pp. 75–105. [HWP99] Hopkins, T.; Whitford, I.; Pidd, M.; Winter, M.: Handling Strategic Problems: Methodologies. http://www.orsoc.org.uk/about/teaching/strategicproblems/m s 3frs.htm. Accessed on February 15th 2011. [Ish86] Ishikawa, K.: Guide to Quality Control.. 2nd Edition. Asia Productivity Organization, Tokyo. 1986. [KV07] Kolfschoten, G.L.; Vreede, G.J. de: The Collaboration Engineering Approach for Designing Collaboration Processes CRIWG, Springer, Heidelberg, LNCS volume 4715, 2007; pp. 95–110. [Lan05] Lankhorst, M. et al: Enterprise Architecture at Work: Modelling, Communication, and Analysis. Springer Berlin, Heidelberg, 2005. [NBP10] Nakakawa, A.; Bommel, P. van; Proper, H.A.: Challenges of Involving Stakeholders When Creating Enterprise Architecture. EIS, Eindhoven, The Netherlands, CEUR-WS 662, 2010; pp. 43–55. [NBP11] Nakakawa, A.; Bommel, P. van; Proper, H.A.: Definition and validation of requirements for collaborative decision making in enterprise architecture creation. International Journal of Cooperative Information Systems (IJCIS), 20(1), 2011; pp. 83–136. [Sta95] The Standish Group.: The Standish Group Report – CHAOS Report, 1995. http://spinroot.com/spin/Doc/course/Standish Survey.htm. Accessed March 3rd 2011. [VB05] Vreede, G.J. de; Briggs, R.O.: Collaboration Engineering: Designing Repeatable Processes for High-Value Collaborative Tasks HICSS, IEEE, 2005. [Wak08] Wakiso District Council: Three Year Development Plan for Wakiso District Wakiso District Local Government offices, 2008. 50 Integration of Process Constraints from Heterogeneous Sources in Process-Aware Information Systems Stefanie Rinderle-Ma and Juergen Mangler University of Vienna, Austria Faculty of Computer Science {stefanie.rinderle-ma,juergen.mangler}@univie.ac.at Abstract: Business Process Compliance (BPC) has gained significant momentum in research and practice during the last years. Although many approaches address BPC, they mostly assume the existence of some kind of unified base of process constraints and focus on their verification over the business processes. However, it remains unclear how such an integrated process constraint base can be built up, particularly at the presence of process constraints stemming from heterogeneous sources such as internal controls, external contracts, or security and privacy policies. Hence in this paper, we propose a representation framework for the integration of process constraints stemming from different sources. The representation framework is generic such that existing formalisms to represent process constraints can be integrated. The framework is illustrated by means of real-world process constraints from different domains and heterogeneous sources. Altogether process constraint integration enables consistency checks and optimizations as well as maintenance and evolution of the constraint base. 1 Introduction Business Process Compliance (BPC) has become a major challenge for enterprises nowadays. BPC requires that business processes comply with certain relevant rules, regulations, or norms. Although many approaches address BPC [NS07, LSG07, SGN07, LRD10, AWW11], they mostly assume the existence of some kind of integrated base of process constraints and focus on the verification of these constraints over the business processes. By process constraints we refer to those rules in the domain of interest, that are associated with processes. As literature and practice show, the co-existence of processes and process constraints is common and desired [HG09, LRD10]. However, it remains unclear how such an integrated process constraint base can be built up and used for compliance checks within the Process-Aware Information System (PAIS), even though this constitutes the essential prerequisite for all further compliance checks. The particular challenge of providing an integrated process constraint base results from the heterogeneity of sources process constraints might stem from. First of all, the sources and purposes of process constraints might be different. Examples comprise internal quality directives such as Six Sigma or ITIL, external controls such as standards (e.g., ISO 001), regulations by authorizing bodies, guidelines [PT09], or regulations based on contracts (business contracts) [SGN07]. For a specific application scenario consider Fig. 1 51 Figure 1: Process Constraints Stemming from Heterogeneous Sources Imposed on Current PAIS that displays example processes and rules from the medical domain: here, business processes might be subject to medical guidelines [PT09] on the one side and also subject to authorization and privacy constraints on the other side. Fig. 1 also covers simple resource synchronization as well as temporal rules. The basic challenge is to integrate all these different kinds of process constraints within one representation in order to enable consistency checks, integrated compliance verification, and a better support for constraint base maintenance. The latter becomes important since process constraints are often subject to change and evolution [LRGD09]. In this paper, we present a framework that enables the integrated representation for process constraints stemming from heterogeneous sources.1 The framework covers process perspectives such as control flow, data flow, time, and resources that can be subject to process constraints. The integrated representation also enables the specification of behavior which is relevant for process constraints that require some sort of action (e.g., synchronization between process instances). The design of the representation framework also enables the integration of existing specification formalisms for process constraints, for example, SeaFlows [LRD10], logic-based rules [PSvdA07], or BPMN-Q constraints [AWW11]. The unified representation is validated against a selection of real-world process constraints. We further discuss how such a framework can be implemented within PAIS. Altogether the proposed approach provides a first step towards the integrated management, verification, and evolution of process constraints in PAIS, tackling the challenge 1 An extended version is available as technical report [MRM11]. 52 Figure 2: Process Constraint Properties of heterogeneous sources for process constraints. Sect. 2 discusses constraint properties in PAIS. The representation formalism for integrated process constraints is presented in Sect. 3 followed by an evaluation in Sect. 4. Sect. 5 compares related approaches and Sect. 6 concludes with summary and outlook. 2 Constraint Properties in Process-Aware Information Systems In the previous sections, a unified representation for process constraints has been presented. In this section, we discuss its usage within Process-Aware Information Systems (PAIS) along different constraint properties as set out in Fig. 2. Usage: Process constraints can be used to verify the compliance of business processes with relevant regulations and constraints. This is useful for process design and evolution. Constraints can also be used to alter or affect the behavior of processes (behavioral). Affecting the behavior of processes includes the attribution of process activities or, more generic, the attribution of structural patterns. Examples include resources allocation of process activities. Additionally, constraints can be used to specify meta constraints. Meta constraints are intended to check the consistency of other constraints, for example, constraint C5 in Fig. 1. Another example is a meta constraint specifying that for each process activity referring to a resource centrifuge synchronization constraint C10 in Fig. 1 is assigned to. Application: Application deals with the question at which phase of a process life cycle constraints may be enforced. Basically, at design-time constraints are checked to verify that a process complies to certain criteria (compliance) constraints. All constraints that are checked at design-time are compliance constraints or meta constraints. All behavioral constraints, and some compliance constraints are checked at run-time. Examples include the checking for data value constraints, or the attribution of structural patterns (the attributes are used at run-time, though can be checked by meta constraints at design-time). Compliance constraints may affect run-time under certain circumstances. E.g. although a process may not conform to a specific constraint at design-time, it may do so at run-time, because only a certain execution path violates the constraint. Hence corresponding process instances are to be monitored at run-time [LRD10]. Scope: The most important scope perspective is structure as in all constraints structural 53 information has to be present (either explicit or implicit through connections of information to structure), as otherwise they would not be connected to processes and could thus not be enforced in PAIS. Note that if a constraint holds on only structural information, it is always a compliance constraint. Data is also an integral part of a process tightly connected to structure. At design-time, it is possible to check if data types and data flow conform to a certain schema. Further it can be checked whether certain data values will lead to compliance violations are runtime. If, for example, a treatment process states that a lab test is to be performed for all patients beyond 65 years and the corresponding medical guideline states that the lab test is mandatory for patients beyond 62 year, it can be already checked at design-time, that for patients between 62 and 64 there will be a violation of the corresponding constraint at run-time. Resource and time are attributes that are typically connected to structure (or data). Their purpose is to describe information that aids the execution of a process. Resource-aware and time-aware constraints in PAIS are typically checked or enforced at run-time including: • Resource assignment to process activities, typically specified based on access constraints (e.g., constraint C11 in Fig. 1). Based on role assignment, process activities are offered to authorized actors in their work lists at run-time (e.g. by a RBAC component). • On top of access constraints, authorization constraints can be specified such as dynamic separation of duties. Dynamic authorization constraints are verified during run-time. • Assign temporal information to activities (e.g. the normal duration of a certain activity is 2 hours with a standard deviation of 10 minutes). Origin: All constraints become available through not specified external resources, either at design time, run-time or change time. They are identified and structured by constraint designers and then made available through a constraint-base, and have to be enacted from this point on. One exception is constituted by SLAs for dynamic service selection. These constraints become available through execution of a process instance, and vanish after the instance finishes. 3 A Framework for Process Constraint Integration In this section the framework for integrating process constraints in PAIS is introduced that should cover all constraint properties set out in Section 2. As fundamental property, process constraints are associated with one or several processes that are implemented and executed within the PAIS of interest. As process literature study shows, all formalisms on process constraints (implicitly) incorporate a structural pattern that contains at least one activity either executed within a process or stored within the process activity repository. 54 In the SeaFlows project [LRD10], for example, process constraints are tied to one or more process activities and consist of an antecedent and a consequence part. More precisely, based on a triggering antecedent pattern, a consequence pattern must hold to fulfill the constraint. Process constraints as defined in DECLARE also refer to process activities and the semantics for relations between activities are based on LTL (Linear Temporal Logic) [PSvdA07]. BPMN-Q offers compliance patterns containing structural patterns within the triggering part of the constraint [AWW11]. In the following section we will define an extended concept of Linkage for process constraints that subsumes the structural pattern of the constraint, but might further incorporate information on the Context of the process constraint, i.e., process types or process instances the constraints refer to, and the Trigger position. The latter is required for capturing process constraints that can trigger an action such as synchronization. 3.1 Expressing Process Context by Linkage The following definition of Linkage integrates the Contextc of a process constraint c together with its structural pattern SPc and a trigger position TPc (cf. Fig. 3). Definition 1 (Linkage) Let P be a set of all process types of consideration and IP be the set of process instances running according to a process type P ∈ P. A process type P ∈ P is described by a process schema SP := (AP , EP , DP )2 where AP denotes the set of activities, EP the set of control/data edges, and DP the set of data elements SP consists of. Then the linkage Linkagec to a process type P is defined as follows: Linkagec ⊆ Contextc × SPc × TPc Contextc ⊆ P × IP ∃SPc TPc ∈ ∅, before(an,P ), after(an,P ) where ∧ ∧ In Def. 1, Contextc describes in which processes or process instances a constraint may occur. Possibilities include single instances (e.g. SLAs for services that have been dynamically selected), all instances of a process (attribution of resources to tasks) or even instances in multiple processes (when a resource is used in multiple processes, and synchronization has to take place). Structural patterns SPc express the association between process constraint and process. In connection with context, it defines for which parts of process types and process instances the corresponding process constraint is to be enforced or verified. Structural patterns may not only spawn single activities but also several activities connected through complex control decisions. Finally, the trigger position TPc is relevant for synchronization constraints, since synchronization constraints are constraints that not only set out certain conditions on process execution, but enforce an action. In this 2 In order to stay meta-model independent, we assume a simple generic representation for process schemas that can be adopted by any (imperative) process meta model. 55 case the trigger position specifies whether the action should take place before the affected activity is started or after. The Trigger Position is solely present for run-time (behavioral) constraints. As a structural pattern may not only spawn a single activity but also several activities connected through complex control decisions, it is necessary to determine when exactly a constraint has to fire. This is the equivalent of describing the condition under which an event occurs, in an Event Condition Action (ECA) rule. The trigger position itself is simple: before or after an activity occurs. Of course multiple before / after positions can be specified. Both, SPC and TPc are grouped as Connection in Fig. 3 to express their tight integration. A TPc can not exists without a set of activities matched by a structural pattern SPc . Apart from TPc , linkage information can be statically matched against processes, thus it is possible to determine enabled and idle constraints (as described before). From now on we will denote a linkage Linkagec in the compact form: Linkagec : ((P, IP ), SPc , TPc ) Consider compliance constraint C6 depicted in Fig. 1: “C6: operation, patient must be examined”. Before any invasive The antecedent pattern “existence of activity invasive operation” within a process triggers the check whether this activity is preceded by an activity “patient examination”. The linkage for this compliance constraints turns out as LinkageC6 : ((Invasive Surgery, ALL), SPC6 , ∅) with SPC6 : ∃a1 Is(a1 , examine patient) ∃a2 Is(a2 , conduct surgery) a1 A ∗ a 2 ∧ ∧ where A∗ : arbitrary activities between a1 and a2 3.2 Integrating Data, Time, and Resources Existing approaches mostly deal with control flow constraints, i.e., constraints that are only referring to structural patterns within a process [AWW11]. The only approaches that have addressed data flow aspects within process constraints are SeaFlows [KLR+ 10] and BPMN-Q [AWW11]. In accordance to these approaches, the data flow perspective within a process constraint can be represented as condition on the structural pattern it refers to. Consider constraint C8 from Fig. 1: “C8: Beyond age 62, a blood test must be performed”. 56 Figure 3: Process Constraint Structure (Integrated Representation) We can see that the data flow condition “Beyond age 62” imposes a restriction on the structural pattern of the constraint (“blood test”). However, control and data flow are only two perspectives of a process. As case studies show, process constraints might also refer to conditions on time and resources, e.g., constraints C3, C4, C5, C7, C9, and C11 within the example depicted in Fig. 1. Hence, constraint integratoin requires the specification of data, time, and resource conditions on top of the linkage part of the constraint. Definition 2 (Condition) Let c be a process constraint with linkage Linkagec referring to a process type P described by process schema on linkage SP := (AP , EP , DP ). The condition of c imposed on Linkagec is defined as Conditionc ⊆ expr(DP ) × expr(timec ) × expr(resourcec ) where • expr(DP ) denotes a logical expression over the data elements of P • expr(timec ) denotes a temporal expression and • expr(resourcec ) denotes a logical expression over the resources associated with P (typically modeled within a organizational or resource model) It is important to mention that a condition cannot exist without referring to a linkage. Thus, a condition describes, under the premise of a given linkage, either (a) a combination of data, temporal or resource conditions that have to be present or (b) a combination of data, temporal or resource conditions that have to be present in order for a given behavior to be apply. For constraint C6, for example, no specific condition is imposed on the linkage part. Hence: ConditionC6 : ∅ When considering constraint C3 in Fig. 1, things get more interesting, since “After a blood test wait 4 hours before sonography” obviously imposes a time 57 condition on the linkage part. Less obviously, an additional condition is imposed on the data flow, since the 4 hours time frame between blood test and sonography are only required for the same patient, formally: LinkageC3 : (Invasive Surgery, ALL), SPC3 , ∅) with SPC3 : ∃a1 Is(a1 , blood test) ∃a2 Is(a2 , sonography) a1 A∗ a2 ∧ ∧ and ConditionC3 : patient(a1 ) = patient(a2 ) min time between(a1 , a2 , 4h) ∧ Similar considerations can be made for data (“C8: beyond age 62”) and resources (C7: examination by same user as surgery) which can be also represented by a condition part imposed on the linkage of a constraint. 3.3 Expressing Behavior within Process Constraints The last missing piece is, given a certain linkage and condition, to allow for a certain assignment or behavior. Assignment becomes necessary for access constraints such as C11. Behavior specifies for example the action part of a synchronization constraint such as C10. Hence, we complete the unified constraint representation by a Behavior part. Definition 3 (Behavior) Let c again be a process constraint. For a given Linkagec and Conditionc , a behavior can be either empty, the attribution of resource or time information or instructions specific for process execution (e.g. exceptions). 3.4 Summary: Linking, Condition, Behavior The overall representation for process constraints consisting of linkage, condition, and behavior is summarized in Fig. 3. In Sect. 4 we will evaluate the unified representation against all case study constraints shown in this paper and existing related approaches. 4 Evaluation In Sect. 4.1, we show how a selection of real-world process constraints can be expressed based on the integrated representation framework . In fact, we have analyzed several 58 application domains and related rules within SeaFlows [LRD10] throughout the last 5 years. Additionally, the examples from the medical domain (cf. Fig. 1) are analyzed. 4.1 Process Constraints from Different Domains Medical Guidelines: A first medical guideline taken from the report “Prevention, Detection, Evaluation, and Treatment of High Blood Pressure” [U.S03] is depicted in Fig. 4-R1) together with a fragment of a corresponding treatment process. An analysis of this constraints over the process shows that blood pressure ≥ 20/10 mmHg above goal blood pressure refers to the data perspective (data element blood pressure) and part initiating therapy refers to structural pattern initiate therapy). 631 .$4!,A< CB!4$<!@$ > ;<''4 8#$==B#$ =<;;: AKN998KN *( L<;;: AKN998KN %9 7 654$5 >>3O !L;+N O;!< L<;;: AKN998KN2 );'9%:NK!#%;' 9M;8<: LN O%+N' #; %'%#%!#%'O #MNK!A@ 1%#M #1; !ON'#92 ;'N ;( 1M%)M 898!<<@ 9M;8<: LN ! #M%!0%:N/#@AN 601 .$4!,A< CB!4$<!@$ > 5A,,!@A&!'@ .MN >%'%>8> !ON (;K #MN (%K9# :;9N %9 9%? 1NNJ9, .MN 9N);': :;9N %9 #; LN !:>%'%9#NKN: !(#NK ! >%'%>8> ;( I 1NNJ9 %( #MN (%K9# :;9N !:>%'%9#NKN: !# !ON 7 $6 >;'#9 !': )8KKN'# !ON H 6I >;'#M92 ! >%'%>8> ;( G 1NNJ9 F!9 (%'!< :;9NE !# !ON 7 $6 >;'#M !': )8KKN'# !ON LN#1NN' 6I !': DC >;'#M9, B;K MN!<#M@ )M%<:KN'2 '; (8K#MNK :;9N9 'NN:N: %( #MN #MN (%K9# :;9N !:>%'%9#NKN: !# !ON 7 6I >;'#M, *'%#%!#N #MNK!A@ ,,, N?!>%'N "ON &;9N$ (7!#=& 4'=$20/ -+) =&A&?%$A<&%9: -%+N (%K9# :;9N * -%+N 9N);': :;9N ('&%$#"!=$: Figure 4: Medical Guidelines The second medical guideline (cf. Fig. 4-R2) describes the vaccination of children for Pneumococcal [PT09]. This guideline refers to the data perspective, e.g., data element age) and structural pattern SPR2 : ∃a1 Is(a1 , give first dose) ∃a2 Is(a2 , give second dose) a1 A∗ a 2 ∧ ∧ In addition, it refers to temporal aspects, i.e., certain time intervals between vaccination should be maintained. Financial Sector: Fig. 5-R3 shows a financial regulation taken from regulatory package BASEL II [Bas06]. Here the basic question is whether “capital ratio” is a process data element or an application data element, i.e., whether the constraint refers to the data perspective or application perspective. If we assume that capital is solely application data as depicted for Process P1, the constraint above does not refer to any structural aspect of the process and hence is not considered as process constraint. By contrast, as for Process P2, the capital ratio is still calculated by the application connected with activity calculate. However, the value is explicitly written as process data element ratio. Consequently, the linkage part of the constraint refers to structural pattern calculate. Authorization: Separation of duties is one example for authorization constraints [SM10]. Assume the constraint depicted in Fig. 6-R4. It refers to the functional perspective 59 "!6 531/1-3/4 "20.4/,3+1 * )313(.( '/&3,/4 "2%.3$2(21,# 4!3%"<< 4D1 0." %'+?#'& !'#?3 ?< %'&%$&'#") $<?CA #." )">?C?#?3C 3> !"A$&'#3!; %'+?#'& 'C) !?<985"?A.#") '<<"#<* 0." #3#'& %'+?#'& !'#?3 2$<# /" C3 &35"! #.'C -,* 0?"! E %'+?#'& ?< &?2?#") #3 DBB, 3> 0?"! D %'+?#'&* @***= 03#'& !?<985"?A.#") '<<"#< '!" )"#"!2?C") /; 2$&#?+&;?CA #." %'+?#'& !":$?!"2"C#< >3! 2'!9"# !?<9 'C) 3+"!'#?3C'& !?<9 /; DE*7 @?*"* #." !"%?+!3%'& 3> #." 2?C?2$2 %'+?#'& !'#?3 3> -,= 'C) '))?CA #." !"<$&#?CA >?A$!"< #3 #." <$2 3> !?<985"?A.#") '<<"#< >3! %!")?# !?<9* 6'#?3 ('&%$&'#" !?<9 *** 4!3%"<< 4E1 ('&%$&'#" !?<9 *** Figure 5: Financial Regulation (BASEL II) based on the corresponding process activities requisite purchase and approve purchase. Further it refers to the organizational perspective by imposing a mutual exclusion constraint on process resources. "!4 31/-+20.,/0+* ) ('&,2,/0+* +% $1/# ,/" 5"340. +/0 3"87646260.4 2/" 5731/-4" 0* )00(4 03 4"3'61"4 4/07&( .02 %" 2/" 5"340. +/0 -5530'"4 2/" 5731/-4"# !"340. !"340. $"8764260. 5731/-4" 95530'" 5731/-4" Figure 6: Authorization Service Level Agreements (SLAs): The following constraint (cf. Fig. 7-R5) was taken from http://aws.amazon.com/ec2-sla/. Its linkage refers to the corresponding process via structural pattern file claim, to the data perspective for the decision constraint ServiceYear-Unavailable < 99.5, and to the time perspective via restrictions over the trailing. Further (SLAs) can be found in regulation packages for internal quality such as Six Sigma or ITIL. 642 /$#-!+$ )$-$> <9#$$7$5& 3 10&!7$ <9#$$7$5& ! %>;85#&2 %$/ -('& $ %'$(# $/+ 8(#& 8)&(2 !//>$' DB8(#& @&2%&/8$=& 5:&2 8)& 82$('(/= 741 .$+; .25B; ,&'5H FF"F1C" !//>$' DB8(#& @&2%&/8$=& (; %$'%>'$8&. ,+ ;>,82$%8(/= -25# A??C 8)& B&2%&/8$=& 5- 1 #(/>8& B&2(5.; .>2(/= 8)& <&2:(%& 9&$2 (/ H)(%) !#$65/ 30J H$; (/ 8)& ;8$8& 5- I&=(5/ D/$:$('$,'&" G- +5> )$:& ,&&/ >;(/= !#$65/ 30J -52 '&;; 8)$/ 741 .$+;E +5>2 <&2:(%& 9&$2 (; ;8('' 8)& B2&%&.(/= 741 .$+; ,>8 $/+ .$+; B2(52 85 +5>2 >;& 58)& ;&2:(%& H('' ,& .&&#&. 85 )$:& )$. A??C I&=(5/ !:$('$,('(8+" 5- 8)& ;&2:(%& H('' ,& .&&#&. 85 )$:& )$. A??C I&=(5/ !:$('$,('(8+" /$#-!+$.$,# 15,-,!>@ ? ==@4; """ *('& %'$(# * * ('&%$#"!:$8 Figure 7: Uptime Agreement 4.2 Evaluation The feasibility of the unified representation is evaluated by means of the overall 16 process constraints and along the constraint properties described in Section 2. For this we classify the 16 process constraint into different constraint types that embody a combination of properties as represented by the unified representation. As depicted in Tab. 1 we identified 14 different process constraint types. The first two constraint types deal with Resource Attribution (e.g., roles, actors, nodes) and Timing Information Attribution (e.g., minimal, maximal, average duration) to process structure. All 60 Table 1: Constraint Types this information is necessary at run-time, for a temporal monitor as a basis to verify if a process behaves correctly, or an RBAC system to select actors in a worklist. The only difference between these two is, that during change-time timing information may have to be adapted to account for the duration of changes. E.g. constraint C11 in Fig. 1 can represented as follows: LinkageC11 SPC11 ConditionC11 BehaviorC11 : ((Invasive Surgery, ALL), SPC11 , ∅) : ∃a1 Is(a1 , affirm diagnosis) :∅ : {ROLE := Doctor} with For attribution TPc is always empty, as the matched structural pattern implies, that the attribution is available all the time. The third constraint type describes Business Compliance Constraints in general. We decided to include this very generic constraint type (which should not be confused with several of the other constraint types) to show some specific characteristics we derived by studying constraint sources. Business compliance constraints, are exclusively compliance constraints, they never carry a behavioral part, they most of the time verify a certain structure of the process, with a possibility of checking also data, resource and temporal aspects. Therefore the design-time Structural constraints also in this list are Business Compliance Constraints, as well as some Temporal Constraints or Data constraints (whenever only design-time aspects are covered). Separation / Binding of Duty, Resource Attribution, and Timing Information Attribution are the exception to the rule. They may be very well applied at design time, just only the impact can only be seen at run-time. 61 Figure 8: Unified Constraint Optimization and Checking 4.3 Application Scenarios for Integrated Process Constraint Representation Fig. 8 illustrates how presented approach can streamline the maintenance and evolution of new process constraints within Process-Aware Information Systems (PAIS). • Process constraints can be identified based on structural patterns and enriched with process context. At some point it may be necessary to create new processes (structural constraints often trigger the creation or evolution of existing processes). • Constraints can be expressed and stored in an integrated manner based on the representation presend in this paper. • Based on the integrated representation, constraint consistency checking and optimization can be supported by an automatic process. Because all constraints are available in a single consistent representation, (unlike for current approaches) it is easily possible to check if inconsistencies between constraints exists (particularly if they stem from different sources), rather than checking consistency between pure structural process constraints only. In current approaches the constraints are embedded and encapsulated in different components of the PAIS (e.g., process engine and organizational model) such that integrated checks are not possible. • Constraint enactment is also different from current approaches. As depicted in Fig. 8 step (1) the Linkage can be matched on behalf of the PAIS, the checking of condition and the enactment of behavior can be move to (potentially external) components. 5 Related Work Many approaches for checking BPC either at design or run time exist, e.g., [LSG07, SGN07]). As argued before, an integrated constraints representation has been outside 62 Representation DECLARE [PSvdA07] control flow pat. BPMN-Q [AWW11] Linkage SeaFlows [LRD10] activity set Condition Behavior data – – – data – control flow pat. global scope Integrated Representation control flow pat. process context trigger position data, time, resource ! Table 2: Comparison of Existing Approaches the scope of these approaches so far. Validation of the integrated representation compared to selected existing approaches is presented in Table 2. The above mentioned approaches try to ensure BPC either a-priori at design time or by detecting inconsistencies at run-time. In addition, there are also a-posteriori approaches that offer techniques to analyze process logs (i.e., data of already executed and finished processes) with respect to certain properties such as adhering to compliance constraints [vdAdBvD05]. In these approaches, different aspects logged during process execution can be checked, e.g., separation of duties. Doing so the a-posteriori approach reflects the need for unified compliance checking, not only a-posteriori, but also a-priori. Other approaches use constraints to synchronize between business processes of different type (e.g., between a chemotherapy and a radiation process) [Hei01]. Based on our approach, synchronization constraints can be unified and managed in combination with the other constraints in PAIS. 6 Summary and Outlook This paper introduced a framework for the integrated representation of process constraints in PAIS. First of all, the basic concepts of the framework were introduced, i.e., Linkage that contains the structural pattern of the process the constraint refers to, the Context, i.e., the process types or instances for which the constraint is imposed, and the Trigger Position that equips the constraints with actions that migth be triggered by the constraint, e.g., for synchronization. Further, the framework was enriched by coping with data, time, and resource information provided within the constraints. Finally Behavior was specified that serves for resource attribution or exception handling, for example. Based on different realworld examples the feasibility of the representation has been shown. Further perspectives on the usage of the presented framework for consistency checks and compliance verification were discussed. Finally, it was shown how existing formalisms for specifying process constraints can be expressed by the representation framework at hand. Currently we are working on an implementation representation framework on top of our adaptive process engine CPEE. Particular focus will be put on maintenance of the constraint base and an integrated verification component for the engine. 63 References [AWW11] A. Awad, M. Weidlich, and M. Weske. Visually specifying compliance rules and explaining their violations for business processes. Journal of Visual Languages & Computing, 22(1):30–55, 2011. [Bas06] Basler Ausschuss fuer Bankenaufsicht. Internationale Konvergenz der Eigenkapitalmessung und Eigenkapitalanforderungen, 2006. [Hei01] C. Heinlein. Workflow and Process Synchronization with Interaction Expressions and Graphs. In Proc. Int’l Conf. on Data Engineering, page 243–252, 2001. [HG09] Barbara Halle and Larry Goldberg. Business Process Models and Business Rules: How They Should Work Together. In The Decision Model: A Business Logic Framework Linking Business and Technology. Taylor & Francis, LLC, 2009. [KLR+ 10] D. Knuplesch, L.T. Ly, S. Rinderle-Ma, H. Pfeifer, and P. Dadam. On Enabling DataAware Compliance Checking of Business Process Models. In Int’l Conf. Conceptual Modeling, volume 6412, pages 332–346, 2010. [LRD10] L.T. Ly, S. Rinderle-Ma, and P. Dadam. Design and Verification of Instantiable Compliance Rule Graphs in Process-Aware Information Systems. In Proc. Int’l Conf. on Advanced Systems Engineering, pages 9–23, 2010. [LRGD09] T. Ly, S. Rinderle-Ma, K. Göser, and P. Dadam. On Enabling Integrated Process Compliance with Semantic Constraints in Process Management Systems - Requirements, Challenges, Solutions. Information Systems Frontiers, pages 1–25, 2009. [LSG07] R. Lu, S. Sadiq, and G. Governatori. Compliance Aware Process Design. In Proc. Int’l Business Process Management Workshops ’07, 2007. [MRM11] Juergen Mangler and Stefanie Rinderle-Ma. IUPC: Identification and Unification of Process Constraints. CoRR, abs/1104.3609, 2011. [NS07] K. Namiri and N. Stojanovic. Pattern-Based Design and Validation of Business Process Compliance. In Int’ OTM Conferences 2007, Part I, volume 4803 of LNCS, page 59–76. Springer, 2007. [PSvdA07] M. Pesic, H. Schonenberg, and W.M.P. van der Aalst. DECLARE: Full Support for Loosely-Structured Processes. In Int’l Enterprise Computing Conference (EDOC’07), page 287–300, 2007. [PT09] M. Peleg and S. W. Tu. Design patterns for clinical guidelines. Artificial Intelligence in Medicine, 47(1):1–24, 2009. [SGN07] S. Sadiq, G. Governatori, and K. Naimiri. Modeling Control Objectives for Business Process Compliance. In Proc. BPM ’07, pages 149–164, 2007. [SM10] M. Strembeck and J. Mendling. Generic Algorithms for Consistency Checking of Mutual-Exclusion and Binding Constraints in a Business Process Context. In OTM Conferences (1), pages 204–221, 2010. [U.S03] U.S. Department of Health and Human Services. 7th Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure. Technical Report 03-5233, National Heart Lung and Blood Institute, 2003. [vdAdBvD05] W. van der Aalst, H. de Beer, and B. van Dongen. Process Mining and Verification of Properties: An Approach based on Temporal Logic. In Int’l OnTheMove Conferences, volume 3761, page 130–147, 2005. 64 Workflow Nets with Roles Robin Bergenthum, Jörg Desel, Sebastian Mauser FernUniversität in Hagen, Germany firstname.lastname@fernuni-hagen.de Abstract: We formalize the usual static role concept for workflow nets, introduce dynamic roles and define soundness as well as a second correctness criterion, called consistency, for workflow nets with roles. We study the relation between the notions of consistency and soundness of workflow nets with and without roles. In particular, we show that a sound workflow net extended by consistent roles is again sound. 1 Introduction The focus of formal business process modeling and related analysis methods is mainly on the control flow perspective. However, there is also research [HSV06, JKJ10, BBS07, RAHE05, PA07, RAH09, Pri08] on the resource perspective of business processes, i.e. on the people, systems and machines actually doing the work. In this paper we formally model human resources, i.e. the actors enabling a business process. In this context, a central question is which actors are allowed to work on a given task of a process. Similar to the concept of role-based access control (RBAC) in the domain of IT-security [SCFY96], business process modeling languages as well as industrial workflow systems usually consider roles as an intermediary concept between tasks and actors [TCG04, RAHE05, AH02]. The permission to execute a task is associated with one or more roles, and conversely also actors are assigned to roles, thereby acquiring the permissions of the roles. Roles are mostly determined by the organizational units (also called groups) and the positions within an enterprise, but also skills and responsibilities are regarded. Typical modeling constructs for assigning roles to tasks are swimlanes referring to roles as in BPMN and EPCs or an annotation of tasks with roles as common for workflow (Petri) nets [AH02, Aal98, Wes07]. In this paper, we provide a formal semantics of the usual role concept for workflow nets by a translation into Colored Petri nets (CP-nets) [Jen97]. There already exist papers that show how to model resource allocation and the handling of resources available for process instances by CP-nets [PA07, RAH09] (there is also some work considering nets in nets [Pri08] and plain Petri nets [JKJ10, HSV06]). These papers focus on the distribution of work items, resource allocation patterns, resource management, etc. These aspects are important for workflow systems, but they go beyond the role concept of workflow nets. Moreover, we do not restrict our considerations to static roles but also define a formal semantics for workflow nets with dynamic roles which have informally been introduced in [BDHM11] in the context of learning processes. In learning processes it is common that the learners dynamically change their roles. Depending on executed learning tasks they gain additional knowledge or responsibilities and therefore their role in the process can 65 change which then influences the allocation of further tasks. Besides the intended applicability for learning and teaching processes, workflow nets with dynamic roles are useful for formally modeling and analyzing business processes with complex authorization constraints. In particular, the principles of separation of duty (SoD) and binding of duty (BoD) [TCG04] can nicely be represented by dynamic roles. For instance, when writing a review an actor gets a new role which is later on required for presentation of the review (BoD) but prohibits writing a second review (SoD). In the literature, there are several interesting approaches, mostly based on RBAC concepts [SCFY96], which introduce specific additional model constructs and notations for explicitly representing authorization constraints in the context of workflows, e.g. [TCG04]. The definitions of workflow nets with static and dynamic roles in this paper enable formal methods. In particular, it is possible to define behavioral correctness criteria regarding these role concepts. The most popular correctness criterion for workflow nets is soundness [Aal98, Wes07]. We first extend this notion in a natural way to workflow nets with static and dynamic roles. Then, we introduce a second correctness criterion, called consistency, which requires that the role perspective does not influence the control flow of a model. We briefly show that, in the case of static roles, soundness and consistency have a very simple and intuitive meaning, namely a workflow net with static roles is consistent iff, for each non-dead task, there is at least one actor having one of the roles assigned to the task, and it is sound iff it is consistent and the underlying workflow net is sound. Concerning workflow nets with dynamic roles the notions of soundness and consistency become more difficult. We show that a consistent model is sound iff the underlying workflow net is sound. Counterexamples show that further relations between consistency and soundness do not hold. Lastly, we discuss a characterization of consistency for dynamic roles which regards the role perspective separately from the underlying workflow net. The paper is organized as follows. In Section 2 we recapitulate the standard role concept for workflow nets and define a formal semantics for this concept using CP-nets. In Section 3 we formally introduce and define dynamic roles for workflow nets. In Section 4 we discuss soundness and consistency for workflow nets with static and with dynamic roles. 2 Standard Role Concept The role concepts of most business process modeling languages are similar. They basically allow an assignment of users and tasks to roles. This is also the case for the standard role concept of workflow nets [AH02, Aal98]. This section presents a formal semantics of this concept by translating it into a CP-net-notation. We assume that the reader is familiar with workflow nets and CP-nets. We use the following notations. N denotes the non-negative the powerset of A and NA the set of multisets over integers. For a finite set A, 2A denotes " A A. For m ∈ N we write m = a∈A m(a) · a. If m(a) > 0 we write a ∈ m. Definition 1. A workflow net (WF-net) is a tuple N = (P, T, F, i, f ), where • • • • P and T are finite sets of places and transitions fulfilling P ∩ T = ∅, F ⊆ (P × T ) ∪ (T × P ) is a flow relation, i, f ∈ P are places satisfying (T × {i}) ∩ F = ∅ and ({f } × T ) ∩ F = ∅, for any node n ∈ P ∪ T there exists a path from i to n and a path from n to f . 66 Figure 1: A WFR-net. The behavioral semantics, i.e. the occurrence sequences, of a WF-net is given by considering the corresponding marked Petri net with the initial marking 1 · i. Definition 2. A workflow net with roles (WFR-net) is a tuple N R = (N, R, A, l, r), where • • • • • N = (P, T, F, i, f ) is a WF-net, R is a finite set of roles, A is a finite set of actors, l : T → 2R is a labeling function assigning a set of roles to each transition, r : A → R is a function assigning a role to each actor. This definition represents roles and actors in an intuitive and simple way. It is similar to most standard role concepts for business processes. Each actor having one of the roles associated to a transition is permitted to execute a respective task. Unlabeled transitions (having assigned the empty set) can occur automatically without requiring an actor. Figure 1 shows an example workflow net with roles. There are four actors, one with role R1, two with role R2 and one with role R3. Task A has to be done by an actor with role R1. Then, B and C can be executed concurrently by R2-actors. Afterwards, D requires the role R3. Finally, E can be accomplished by an actor with role R1 or with role R2. To provide a formal operational semantics for WFR-nets, we define a translation into CPnets. We extend the underlying WF-net by a place which serves as a resource pool, containing all actors with their associated roles. The role annotations of transitions are considered by appropriate guards. In this way roles, actors and execution permissions are regarded. We here just provide the definition of a CP-net [Jen97] (black tokens are given by the color set U N IT = {()}). For the operational semantics of CP-nets, see [Jen97]. Definition 3. A colored Petri net (CP-net) is a tuple CP N = (C, P, T, F, V, c, v, g, e, m0 ), where • • • • • • • • • C is a finite set of non-empty types (each type is a set called color set), P and T are finite sets of places and transitions fulfilling P ∩ T = ∅, F ⊆ (P × T ) ∪ (T × P ) is a flow relation defining a set of arcs, V is a finite set of variables, c : P → C is a coloring function assigning a type to every place, v : V → C is a coloring function assigning a type to each variable, g assigns a boolean expression using variables from V to every transition, e assigns an!expression of type Nc(p) using appropriate variables from V to every arc, m0 : P → p∈P Nc(p) assigns an initial marking m0 (p) ∈ Nc(p) to every place p. 67 Figure 2: CP-net corresponding to a WFR-net. Definition 4. Given a WFR-net N R = (P, T, F, i, f, R, A, l, r), we define the corresponding CP-net CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) by • • • • • • • • C = {U N IT, A, R, A × R}, P & = P ∪ {pres }, F & = F ∪ ({t ∈ T | l(t) 3= ∅} × {pres }) ∪ ({pres } × {t ∈ T | l(t) 3= ∅}), V = {x, y}, c(p) = U N IT for p ∈ P , c(pres ) = A × R, v(x) = A, v(y) = R, g(t) = [y = g1 orelse . . . y = gn ] for t ∈ T satisfying l(t) = {g1 , . . . , gn }, e(z) = 1 · () for z ∈ F , e(z) = (x, y) for z ∈ ({t ∈ T | l(t) 3= ∅} × {pres }) ∪ ({pres } × {t ∈ T | l(t) 3= ∅}), " • m0 (i) = 1 · (), m0 (p) = ∅ for p ∈ P \ {i}, m0 (pres ) = a∈A (a, r(a)). In order to fire a transition of the introduced CP-net, the variables x and y have to be bound. In this way an actor x having the role y is allocated to the task. The transition guard ensures that the allocated actor is permitted to execute the task, i.e. it is checked that his role y is assigned to the task in the WFR-net. When an actor executes a task, he is removed from the place pres . As soon as the task is accomplished, the actor is released by giving it back to the place pres . In this way the place pres guarantees that at any time an actor can only be allocated to one task. An exception are tasks of the original WFR-net having an empty set of roles. These automatic tasks require no actor from the resource pool pres . Note that the concept of releasing an actor allocated to a task as soon as the task is completed is an important difference to the approaches in [HSV06, JKJ10, BBS07], where also WF-nets regarding resources are formally discussed. Figure 2 depicts the CP-net corresponding to our example WFR-net from Figure 1. We have restricted ourselves to a basic role model in this section. This basic model can be extended in different directions: • The basic role model does not regard process instances. However, different process instances can easily be distinguished by using a copy of the WFR-net for each instance and connecting each copy with the place representing the resource pool. Then, this place does not only ensure that an actor cannot execute two tasks of one process 68 instance at once but also that an actor cannot execute two tasks of different process instances at once. One resource place can also be used for different process models. Then, the same actors are shared among the process instances of several processes. • In the basic role model an actor can only be assigned to one role, and we do not consider a hierarchy among roles. While these restrictions reduce the modeling comfort, they do not restrict the modeling capabilities, since these aspects can equivalently be represented by the concept of alternative role annotations. For explicitly modeling multiple roles of actors, we can associate sets of roles instead of single roles to each actor. Then, the transition guards check whether a specific role is contained in the set of roles of an actor. A hierarchy among roles can be expressed by a consistency condition on the function assigning sets of roles to actors. • The basic model does not regard collaborative tasks which require a joint execution by several actors with certain roles, e.g. two authors that write a paper together. We can extend the role model by collaborative tasks as follows (see [BDHM11] for details). Instead of one actor, a collaborative task consumes a certain number of actors from the resource pool. To ensure that each of the actors has an appropriate role, we can use the “andalso”-operation in the guards. 3 Dynamic Roles The idea of dynamic roles is to change role assignments of actors depending on tasks executed by an actor, i.e. the role of an actor depends on his task history. We will extend the intuitive modeling language of WFR-nets by this concept. If an actor having a certain role changes his role when executing a task, we represent this by extending the label of the transition. Formally, we simply consider pairs of roles consisting of the old and the new role, i.e. the labeling function now assigns a set of pairs of roles instead of a set of single roles to the transitions. If a role assignment does not change when executing a task, the old and the new role coincide. Definition 5. A workflow net with dynamic roles (WFDR-net) is a tuple NR= (N, R, A, l, r), where • • • • • N = (P, T, F, i, f ) is a WF-net, R is a finite set of roles, A is a finite set of actors, l : T → 2R×R is a labeling function assigning a set of pairs of roles to each transition, r : A → R is a function assigning a standard role to each actor. Figure 3 shows an example workflow net with dynamic roles. There are two actors, both initially having the role R1. Both are allowed to execute task A. Also the concurrent tasks B and C require the role R1, i.e. B as well as C can be accomplished by any of the two actors. However, one and the same actor cannot execute both tasks (separation of duty), since each of them causes a role change. The actor executing B gets the role R2, the one executing C gets the role R3. Therefore, the two actors have to share the two tasks among each other. After B and C, task D can be done by either an R2-actor or an R3-actor, i.e. by any of the two actors. Finally, E has to be executed by an actor with role R2. Thus, this task requires the actor that executed B before (binding of duty). 69 Figure 3: A WFDR-net. Analogously to the last section, we define the semantics of a WFDR-net by a translation into a CP-net. In addition to Definition 4, the dynamic roles of actors are regarded. When firing a transition three variables have to be bound. Besides the actor x, the variable y1 represents the role required to execute the task and y2 represents a role change. Definition 6. Given a WFDR-net NR= (P, T, F, i, f, R, A, l, r), we define the corresponding CP-net CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) by • • • • • • • C = {U N IT, A, R, A × R}, P & = P ∪ {pres }, F & = F ∪ ({t ∈ T | l(t) 3= ∅} × {pres }) ∪ ({pres } × {t ∈ T | l(t) 3= ∅}), V = {x, y1 , y2 }, c(p) = U N IT for p ∈ P , c(pres ) = A × R v(x) = A, v(y1 ) = R, v(y2 ) = R, g(t) = [(y1 = g1,1 andalso y2 = g1,2 ) orelse . . . (y1 = gn,1 andalso y2 = gn,2 )] for t ∈ T satisfying l(t) = {(g1,1 , g1,2 ), . . . (gn,1 , gn,2 )}, • e(z) = 1 · () for z ∈ F ,e(z) = (x, y1 ) for z ∈ {pres } × {t ∈ T | l(t) 3= ∅}, e(z) = (x, y2 ) for z ∈ {t ∈ T | l(t) = 3 ∅} × {pres }, " • m0 (i) = 1 · (), m0 (p) = ∅ for p ∈ P \ {i}, m0 (pres ) = a∈A (a, r(a)). Figure 4 shows the CP-net corresponding to the WFDR-net from Figure 3. Figure 4: CP-net corresponding to a WFDR-net. 70 4 Soundness In this section we discuss soundness of WFR-nets and WFDR-nets. A net may exhibit errors such as deadlocks, livelocks or garbage being left in the process after termination. Soundness is a basic behavioral property that each proper procedure should satisfy. For WF-nets the property states that “for any case, the procedure will terminate eventually, and at the moment the procedure terminates there is a token in place f and all the other places are empty” [Aal98]. Moreover, there should be no dead tasks. Definition 7. A WF-net N = (P, T, F, i, f ) is sound if (S1) From each marking reachable from 1 · i, the marking 1 · f is reachable. (S2) There are no dead tasks w.r.t the initial marking 1 · i. As an example, the WF-net underlying the nets shown in Figure 1 and 3 is sound. Remark that the soundness definition originally included a third property stating that for each marking m reachable from 1 · i with m(f ) ≥ 1, there holds m = 1 · f . However, it was later shown that this property follows from (S1). We now define a notion of soundness of WFR- and WFDR-nets which integrates the resource perspective of business processes. For this purpose we consider the corresponding CP-nets and formulate two requirements generalizing the properties (S1) and (S2). Definition 8. Let NR= (N, R, A, l, r) be a WFR- resp. a WFDR-net and CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) the corresponding CP-net. A marking mf of CP NN R is called final marking if mf (f ) = 1 · () and mf (p) = ∅ for p ∈ P \ {f } Definition 9. Let NR= (N, R, A, l, r) be a WFR- resp. a WFDR-net and CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) the corresponding CP-net. The net NR is sound if (S1’) From each reachable marking of CP NN R , a final marking is reachable. (S2’) CP NN R has no dead tasks. It can easily be verified that the nets in Figure 2 and 4 fulfill the properties (S1’) and (S2’). That means, the WFR-net in Figure 1 and the WFDR-net in Figure 3 are sound. In WFR-nets and WFDR-nets the resource perspective is defined on top of the control flow perspective. The latter is given by a WF-net and the former by role annotations and actors. This concept clearly separates the resource view from the control flow view. Therefore, the actors and roles of a WFR-net resp. a WFDR-net should have no influence on the control flow of the model. They should only describe the resource allocation allowed within the business process. Otherwise, the two views are not consistent. Consequently, besides soundness we in the following introduce a second correctness property which is concerned with consistency of the resource perspective to the control flow perspective. By requiring actors with certain roles for firing transitions, the control flow can only be restricted. That means, if a transition can occur in a certain marking of a WFR-net resp. a WFDR-net this transition is also enabled in the corresponding marking of the underlying WF-net where the corresponding marking is given by just neglecting the place pres . Thereby, a transition occurrence of a CP-net, called binding element, is given by 71 a pair consisting of the fired transition and the firing mode (i.e. the binding of the variables) of the transition [Jen97]. For instance, in the net of Figure 4 the binding element (A, < x = andy, y1 = R1, y2 = R2 >) is enabled. Definition 10. Let NR= (N, R, A, l, r) be a WFR-net resp. a WFDR-net, CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) the corresponding CP-net and m a marking of CP NN R . Then the marking mu of N given by mu (p) = |m(p)| for p ∈ P is called corresponding marking of m. Lemma 1. Let m be a marking of CP NN R . If the binding element (t, b) is enabled in m leading to the follower marking m& , then t is enabled in the marking mu of N leading to u the follower marking m& . Proof. By construction, compared to N , the CP-net CP NN R just has the additional place pres (together with arcs connecting the place with transitions). A well-known property of Petri nets is that adding a place to a Petri net can only restrict the enabledness of transitions and does not influence the markings w.r.t. other places. Figure 5: WFDR-net which is sound but not consistent. It is possible that an enabled transition of N is prohibited in NR, since appropriate actors are missing, i.e. the place pres prohibits the occurrence. If behavior specified by the control flow model cannot occur due to missing actors, this indicates inconsistency between the control flow and the resource perspective, i.e. the resources are not appropriate for the given control flow. Therefore, we formulate the following correctness criterion which ensures the reverse implication to Lemma 1. Definition 11. Let NR= (N, R, A, l, r) be a WFR- resp. a WFDR-net and CP NN R = (C, P & , T, F & , V, c, v, g, e, m0 ) be the corresponding CP-net. The net NR is called consistent if for each reachable marking m of CP NN R and each transition t which is enabled in the marking mu of N , there is a binding b such that (t, b) is enabled in m. Using Lemma 1 we can summarize the following relationship between the behavior of a WFR-net resp. a WFDR-net and the underlying WF-net in terms of occurrence sequences. Lemma 2. If an occurrence sequence (t1 , b1 ) . . . (tn , bn ) is enabled in the initial marking m0 of CP NN R leading to the follower marking m, then t1 . . . tn is enabled in the initial marking 1 · i of N leading to the follower marking mu . In the case NR is consistent we also have: If t1 . . . tn is enabled in the initial marking 1 · i of N , then there are bindings b1 , . . . , bn such that (t1 , b1 ) . . . (tn , bn ) is enabled in the initial marking m0 of CP NN R . Proof. The statements follow from mu0 = 1 · i by inductively applying Lemma 1 and Definition 11. 72 The WFR-net of Figure 1 and the WFDR-net of Figure 3 are both consistent. Figure 5 shows a WFDR-net which is not consistent. However, this net and also its underlying WFnet are sound. The net contains two subsequent alternatives, first between task A and B, then between task C and D. The role annotations ensure that whenever the actor initially executes A, then he next has to execute C, although D is also enabled in the underlying WF-net. Similarly, when starting with B, the actor then has to execute D. Therefore, the role perspective of this net forbids behavior which is allowed by the control flow model, namely the occurrence sequences AD and BC. 4.1 WFR-nets An important observation is that for WFR-nets the correctness property of consistency is already included in the soundness property. Lemma 3. A sound WFR-net NR= (N, R, A, l, r) is consistent. Proof. If NR is not consistent, there is a reachable marking m of CP NN R and a transition t such that t is enabled in the marking mu of N , but for each b the binding element (t, b) is not enabled in m. It follows that the place pres prohibits the firing of t. Since the marking of pres never changes, the transition t is dead in CP NN R , i.e. NR does not fulfill (S2). Consequently, NR is not sound. Since soundness of WF-nets is well investigated, we discuss the relation between soundness of a WFR-net and soundness of the underlying WF-net. It can first be shown that soundness of the underlying WF-net is a necessary condition for soundness of a WFR-net. Lemma 4. If NR= (N, R, A, l, r) is a sound WFR-net, then also N is sound. Proof. If N is not sound, one of the conditions (S1) or (S2) is not satisfied. We show for each case that NR is not sound. If N does not fulfill (S1), then there is a reachable marking m from which 1 · f is not u reachable. Either a marking m& with m& = m is reachable in CP NN R or this is not the case. In the first situation, by Lemma 1, a final marking is not reachable from m& , since a final marking mf fulfills muf = 1 · f . That means NR does not fulfill (S1’). In the second case, by Lemma 2, NR is not consistent and therefore Lemma 3 shows that NR is not sound. If N does not fulfill (S2), then there is a dead task. By Lemma 2 this task is also dead in NR, i.e. NR does not fulfill (S2’). In general, consistency does not imply soundness, since it formulates no requirements on the control flow of the underlying WF-net. Soundness of the underlying net also does not imply soundness of a WFR-net because the WFR-net can contain dead tasks due to missing actors. However, we now show that both properties together, consistency and soundness of the underlying WF-net, ensure soundness of a WFR-net. Lemma 5. Let NR= (N, R, A, l, r) be a WFR-net. If NR is consistent and N is sound, then also NR is sound. 73 Proof. If NR is not sound, one of the conditions (S1’) or (S2’) is not satisfied. We show for each case that either NR is not consistent or N is not sound. If NR does not fulfill (S1’), then there is a reachable marking m of CP NN R from which no final marking is reachable. By Lemma 2, the marking mu is reachable in N . In the case NR is consistent, with Lemma 1 it follows that the marking 1 · f is not reachable from mu , since a marking mf of CP NN R fulfilling muf = 1 · f is a final marking. That means, N does not fulfill (S1). If NR does not fulfill (S2’), then there is a dead task. In the case NR is consistent, by Lemma 2, this task is also dead in N , i.e. N does not fulfill (S2). The previous lemmas imply the following characterization of soundness for WFR-nets. Theorem 1. A WFR-net NR= (N, R, A, l, r) is sound iff NR is consistent and N is sound. This characterization shows how to design sound WFR-nets. First, a sound WF-net is constructed. Then, roles and actors are added in a way which does not influence the control flow given by the WF-net. So far the structural interpretation of the behavioral property consistency is not clear, and thus we do not know how to ensure the property when designing the role perspective of a WFR-net. Therefore, we provide a simple characterization of consistency: Lemma 6. A WFR-net NR= (N, R, A, l, r) is consistent iff, for each transition t with l(t) 3= ∅ which is not dead w.r.t. N , there is an actor a ∈ A such that r(a) ∈ l(t). Proof. If NR is not consistent, the proof of Lemma 3 shows that there is a transition t which is not dead w.r.t. N but cannot fire w.r.t. CP NN R due to the place pres (which has a constant marking). It follows: l(t) 3= ∅ and there is no a ∈ A such that r(a) ∈ l(t). If there exists a transition t with l(t) 3= ∅ which is not dead w.r.t. N such that there is no a ∈ A with r(a) ∈ l(t), then there is a reachable marking m of N which enables t but for any reachable marking m& of CP NN R and any b the binding element (t, b) is not enabled in m& because the constant marking of pres prohibits t. Therefore, if a marking m& with u m& = m is reachable in CP NN R , then NR is not consistent. Otherwise, by Lemma 2, NR is not consistent. From this characterization we can immediately deduce two very simple sufficient conditions for consistency of a WFR-net NR= (N, R, A, l, r) which are purely structural. In particular, they are completely independent from the underlying WF-net N . In the first condition we only remove the restriction to dead tasks from the previous characterization. The second condition is a further simplification abstracting from tasks. It just requires that for each role there is at least one actor having the role. (C1) If, for each transition t with l(t) 3= ∅, there is an actor a ∈ A such that r(a) ∈ l(t), then NR is consistent. (C2) If, for each role x ∈ R, there is an actor a ∈ A with r(a) = x, then NR is consistent. The WFR-net from Figure 1 fulfills (C2), since there is an actor for all three roles. 74 Figure 6: Sound WFDR-net. 4.2 WFDR-nets For WFDR-nets, soundness and consistency become more difficult notions. In contrast to Lemmas 3 and 4 for WFR-nets, soundness of a WFDR-net does neither imply consistency of the WFDR-net nor soundness of the underlying WF-net. The WFDR-net of Figure 6 is sound, although it is not consistent and the underlying WF-net is not sound. The WF-net can run into a deadlock when firing tasks C and F or D and E. However, when firing C and E or D and F the net completes properly. Inconsistent role annotations of the WFDR-net prohibit the deadlocks of the underlying WF-net. We have already discussed that soundness alone is not enough for a WFDR-net. For correctness, we are interested in sound and consistent WFDR-nets. For such nets it is possible to show that the underlying WF-net is also sound. Lemma 7. If NR= (N, R, A, l, r) is a sound and consistent WFDR-net, then N is sound. Proof. If N is not sound, one of the conditions (S1) or (S2) is not satisfied. We show for each case that NR is not sound or not consistent. If N does not fulfill (S1), then there is a reachable marking m from which 1 · f is not u reachable. In the case NR is consistent, by Lemma 2, a marking m& with m& = m is reachable in CP NN R . By using Lemma 1, a final marking is not reachable from m& , since a final marking mf fulfills muf = 1 · f . That means NR does not fulfill (S1’). If N does not fulfill (S2), then there is a dead task. By Lemma 2 this task is also dead in CP NN R , i.e. NR does not fulfill (S2’). Moreover, analogously to Lemma 5 for WFR-nets, consistency of a WFDR-net together with soundness of the underlying WF-net implies soundness of the WFDR-net. Lemma 8. Let NR= (N, R, A, l, r) be a WFDR-net. If NR is consistent and N is sound, then also NR is sound. Proof. The proof is analogous to Lemma 5. The two previous lemmas together yield the following equivalence. Theorem 2. A consistent WFDR-net NR= (N, R, A, l, r) is sound iff N is sound. 75 Altogether, we have shown how to design correct WFDR-nets. First, a sound WF-net is constructed which is then consistently extended by roles and actors. With this approach soundness of the resulting WFDR-net is guaranteed. Still, there are also sound WFDRnets which are not consistent. For such a net it is possible that the underlying WF-net is not sound (Figure 6), but it is also possible that the WF-net is sound (Figure 5). For the sake of completeness note that in the case of a non-sound and non-consistent WFDR-net, the underlying WF-net can be both sound (Figure 5 with empty set of actors) or not sound (Figure 6 with empty set of actors). We now investigate the property of consistency for WFDRnets in detail. The aim is to find a characterization of consistency which explicitly regards the role perspective separately from the underlying WF-net. Then, as it is natural, consistency for the role perspective can be checked on top of the control flow perspective. For this purpose, we introduce the notion of role diagram which describes the dynamic role behavior of all the actors of a WFDR-net as given by the role annotations (neglecting the underlying WF-net). Figure 7 ilFigure 7: A role diagram. lustrates the role diagram of the WFDR-net from Figure 3. The role diagram of a WFDR-net is a non-deterministic finite automaton which models the overall dynamic resource perspective of a WFDR-net. States represent different role combinations of actors, and each transition represents a task that can be executed by a certain role combination as well as the role change triggered by this task execution. Definition 12. A non-deterministic finite automaton is a tuple M = (Q, T, δ, q0 ), where • • • • Q is a finite set of states, T is a finite set of input symbols, δ ⊆ Q × T × Q is a transition relation and q0 ∈ Q is an initial state. Definition 13. Let NR= (P, T, F, i, f, R, A, l, r) be a WFDR-net. The role diagram RN R = (Q, T, δ, q0 ) of NR is defined inductively (Q ⊆ NR ): " • q0 = a∈A r(a) " • If q ∈ Q, q(x1 ) > 0 and (x1 , x2 ) ∈ l(t) for t ∈ T then q & = x∈R\{x1 ,x2 } q(x) · x + (q(x1 ) − 1) · x1 + (q(x2 ) + 1) · x2 ∈ Q and (q, t, q & ) ∈ δ. A WFDR-net is consistent if the resource perspective, i.e. the place pres does not prohibit any behavior of the underlying WF-net. That means, for each reachable state, if the WFnet allows the occurrence of a task, then there are actors capable of executing the task. In particular, the enabledness of a task has to be independent from the assignments of actors to previous tasks. Based on the concept of role diagram we formulate the following characterization for consistency of WFDR-nets. Lemma 9. Let NR= (N, R, A, l, r) be a WFDR-net and RN R = (Q, T, δ, q0 ) the role diagram of NR. Then, NR is consistent iff it fulfills the following property: For each occurrence sequence t1 . . . tn , n ≥ 1, of N and each (q0 , t1 , q1 ) . . . (qn−2 , tn−1 , qn−1 ) ∈ δ there exists qn ∈ Q such that (qn−1 , tn , qn ) ∈ δ. 76 Proof. If NR is not consistent, there is a marking m of CP NN R reachable by an occurrence sequence (t1 , b1 ) . . . (tn−1 , bn−1 ) and a transition tn which is enabled in the marking mu of N , such that (tn , bn ) is not enabled in m for each binding bn . By Lemma 2, t1 . . . tn is an occurrence sequence of N . Moreover, by "construction of RN R it holds (q0 , t1 , q1 ) . . . (qn−2 , tn−1 , qn−1 ) ∈ δ such that qn−1 = (a,x)∈A×R m(pres )(a, x) · x. Since tn is not enabled in m w.r.t. the place pres , it follows that there is no (a, x1 ) ∈ m(pres ) such that (x1 , x2 ) ∈ l(tn ). Thus, there is no x1 ∈ qn−1 such that (x1 , x2 ) ∈ l(tn ). It follows that there does not exist a state qn ∈ Q with (qn−1 , tn , qn ) ∈ δ. If there is an occurrence sequence t1 . . . tn of N and (q0 , t1 , q1 ) . . . (qn−2 , tn−1 , qn−1 ) ∈ δ such that there is no qn ∈ Q with (qn−1 , tn , qn ) ∈ δ, then by construction of RN R and Lemma 2 there are bindings b1 . . . bn−1 such that (t1 , b1 ) . . . (tn−1 , bn−1 ) is an occurrence sequence of CP NN R which leads to a marking m with the following properties: qn−1 = " u (a,x)∈A×R m(pres )(a, x) · x and m is the follower marking of the occurrence sequence t1 . . . tn−1 of N . By assumption there is no x1 ∈ qn−1 such that (x1 , x2 ) ∈ l(tn ) and thus there is no (a, x1 ) ∈ m(pres ) such that (x1 , x2 ) ∈ l(tn ). Consequently, there is no bn such that (tn , bn ) is enabled in m, although tn is enabled in mu , i.e. NR is not consistent. With Lemma 9, consistency of the role perspective can nicely be checked on top of a given WF-net by comparing the marking graph of the WF-net and the role diagram. The maximal occurrence sequences of the WF-net underlying the WFDR-net from Figure 3 are ABCDE and ACBDE. Thus, to verify consistency of the WFDR-net, for each prefix of these sequences we have to check that the property formulated in the previous lemma is satisfied by the role diagram of Figure 7. For instance, given the sequence ABCDE, starting in the initial state of the role diagram there is only one sequence of state transitions corresponding to ABCD. For the follower state R2+R3, it has to be checked that there is a state transition given by the task E. From Lemma 9 we can also deduce reasonable sufficient conditions for consistency of a WFDR-net NR= (N, R, A, l, r) with role diagram RN R = (Q, T, δ, q0 ) which are more simple to check. First, a simplification can be achieved in the case of deterministic role annotations: If the role diagram is deterministic, then it is enough to check whether each occurrence sequence of N is included in the role diagram. Second, we can consider the situation that there are always enough actors to perform each task of the net. For this purpose, we regard the set of all states Q& ⊆ Q of the role diagram reachable by an occurrence sequence of N . That means, Q& represents all reachable role combinations in the resource place pres . We formulate the following condition which is analogous to (C1) for WFRnets: If for each task, each reachable role combination contains a role which is allowed to execute the task, then NR is consistent. Moreover, we can simplify this condition analogously as in the case of (C2) for WFR-nets: If each reachable role combination contains all roles of NR, then NR is consistent. Thereby, the set of all reachable role combinations Q& can be computed by projecting the states of the product automaton of RN R and the marking graph of N onto the RN R -component. (D) If RN R fulfills the property (q, t, q & ), (q, t, q && ) ∈ δ =⇒ q & = q && , then NR is consistent iff RN R accepts each occurrence sequence of N (when considering all states Q as final states). 77 (C1’) If for each t ∈ T with l(t) 3= ∅ and each q ∈ Q& , there exists (x1 , x2 ) ∈ l(t) such that q(x1 ) > 0, then NR is consistent. (C2’) If for each q ∈ Q& and each x ∈ R there holds q(x) > 0, then NR is consistent. Since the role diagram of Figure 7 is deterministic, we can verify consistency of the WFDR-net in Figure 3 by checking condition (D). 5 Conclusion We have shown how to formally extend Petri net process models by static and dynamic role concepts. Then, we have discussed correctness of respective models. An important topic for future research is a detailed discussion of the extensions of the modeling languages mentioned in Section 2. References [Aal98] W. van der Aalst. The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers, 8(1):21–66, 1998. [AH02] W. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. MIT Press, 2002. [BBS07] K. Barkaoui, R. Benayed, and Z. Sba. Workflow Soundness Verification Based on Structure Theory of Petri Nets. IJCIS Journal, 5:51–62, 2007. [BDHM11] R. Bergenthum, J. Desel, A. Harrer, and S. Mauser. Modeling and Mining of Learnflows. In to appear in ToPNoC. Springer, 2011. [HSV06] K. van Hee, N. Sidorova, and M. Voorhoeve. Resource-Constrained Workflow Nets. Fundam. Inf., 71:243–257, 2006. [Jen97] K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use., volume 1-3 of Monographs in Theoretical Computer Science. Springer, 1992, 1994, 1997. [JKJ10] G. Juhás, I. Kazlov, and A. Juhásová. Instance Deadlock: A Mystery behind Frozen Programs. In Petri Nets 2010, LNCS 6128, pages 1–17. Springer, 2010. [PA07] M. Pesic and W. van der Aalst. Modeling Work Distribution Mechanisms using Colored Petri Nets. International Journal on Software Tools for Technology Transfer, 9(34):327–352, 2007. [Pri08] O. Prisecaru. Resource workflow nets: an approach to workflow modelling and analysis. Enterp. Inf. Syst., 2(2):101–120, 2008. [RAH09] N. Russell, W. van der Aalst, and A. ter Hofstede. Designing a Workflow System Using Coloured Petri Nets. pages 1–24. Springer, 2009. [RAHE05] N. Russell, W. van der Aalst, A. ter Hofstede, and D. Edmond. Workflow Resource Patterns: Identification, Representation and Tool Support. In CAiSE 2005, LNCS 3520, pages 216–232. Springer, 2005. [SCFY96] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman. Role-Based Access Control Models. IEEE Computer, 29(2):38–47, 1996. [TCG04] K. Tan, J. Crampton, and C. Gunter. The Consistency of Task-Based Authorization Constraints in Workflow Systems. In CSFW-17, pages 155–169. IEEE, 2004. [Wes07] M. Weske. Business Process Management – Concepts, Languages and Architectures. Springer, 2007. 78 Fast Pattern Matching in Conceptual Models – Evaluating and Extending a Generic Approach Hanns-Alexander Dietrich, Matthias Steinhorst, Jörg Becker, Patrick Delfmann European Research Center for Information Systems University of Muenster Leonardo-Campus 3 48149 Münster {dietrich | steinhorst | becker | delfmann}@ercis.uni-muenster.de Abstract: Identifying structural patterns in conceptual models serves a variety of purposes ranging from model comparison to model integration and exploration. Although there are a multitude of different approaches for particular modelling languages and application scenarios, the modelling community lacks an integrated approach suitable for conceptual models of arbitrary languages and domains. Therefore, a generic set-theory based pattern matching approach has recently been developed. To prove that this approach is beneficial in terms of performance, we conduct a statistically rigorous analysis of its runtime behaviour. We augment the original approach to include a caching mechanism that further increases performance. We are able to show that the original algorithm is able to identify arbitrary patterns within milliseconds. The caching extension further increases performance by up to fifty per cent given the model base and patterns we used. 1 Introduction Structurally analysing conceptual models serves a wide variety of purposes. In the domain of Business Process Management (BPM) it helps detect process improvement potential [VTM08]. In case of mergers and acquisitions, identifying structural patterns in process models allows for comparing heterogeneous process landscapes to one another. Such a comparison can then be used to integrate various process models containing similar or equivalent structures [Di09]. Identifying patterns in conceptual models is also useful for business process compliance checking [Kn10] as well as determining the syntactical correctness of a particular model [Me07]. In the domain of database engineering, detecting structures in conceptual models addresses the problem of schema matching and integration [PS11; RS10]. In all of these application scenarios a manual analysis is extremely costly, since the number of models to be analysed may range in the thousands [YDG10]. Furthermore, each model may contain hundreds of elements. Structural pattern matching can therefore only be beneficial if it is conducted in an automated or at least semi-automated way. To that end, we have developed a generic set-theory based pattern matching approach that is able to find patterns in conceptual models of arbitrary modelling languages [De10]. 79 The approach is based on the idea that any graph-based conceptual model can be regarded as the set of its objects and relationships. The approach was prototypically implemented as a plug-in for a meta-modelling tool that was available from a previous research project [DK07]. To prove that our approach is beneficial in terms of performance, we conduct a statistically rigorous analysis of its runtime behaviour. We evaluate the approach on two sets of Event-driven Process Chains (EPC) [Sc00] that were available from previous research projects as well. In total, we analyse process models having between 20 and 343 elements. The patterns we search for are based on the works of [Me07] who defines syntactical errors in EPCs and [Va03] who identify workflow patterns. We are able to demonstrate that the generic set-theory based approach allows for finding structural pattern matches within milliseconds. We augment the approach to include a caching algorithm that further improves matching performance by up to fifty per cent given the model base and patterns we used. The algorithm is based on the idea of storing frequently used sub-patterns in a data structure that allows access in constant time. The remainder of the paper is structured as follows. In Section 2, we discuss related work. Our analysis indicates that there is no generic pattern matching algorithm that finds matches within milliseconds. In Section 3, we briefly elaborate on the approach to be evaluated. We continue by explaining the caching mechanism augmenting the original algorithm. In Section 4, we provide a detailed performance analysis of the approach both with and without the caching algorithm. We conclude by summarizing our main findings and providing an outlook to future research. 2 Related Work Identifying structural patterns in conceptual models serves multiple purposes in the fields of database engineering and business process management. To identify relevant literature, the keywords ‘schema matching’, ‘business process’, ‘similarity’, ‘merge’, ‘check ’, ‘comparison ’, ‘compliance’, and ‘exploration’ were used in combination with Google Scholar. Primarily, recent literature from the last five years was analysed. We furthermore included some sources from unstructured search. In the field of database engineering, various approaches have been proposed addressing the problem of schema matching and integration. Two or more schemas are taken as input and semantically as well as structurally equivalent elements are identified to create an integrated schema as output [RB01]. Some of these approaches assume the underlying schemas to exhibit a tree-like structure [RS10; TC06; Au05] others identify similar model parts [PS11; SDH08; DHY08]. In the field of business process management pattern matching is closely related to the topic of model analysis, which serves multiple purposes ranging from model comparison [Di10; YDG10; DDG09; AVW08; Kü08; VDM08; EKO07; SM07a; VAW06;] and model merge [La10; WDM10; Di09; SM07b; Gr05; UC04] to model exploration [We11; Kn10; Sm10; We10; Fa09; Sm09; WHM08; Aw07]. 80 All of these approaches address very particular tasks related to the identification of patterns in conceptual models. Furthermore, some of them restrict themselves to specific modelling languages or do not provide exact matching algorithms but approximationbased heuristics. We therefore argue that the modelling community would benefit from a more generic pattern matching approach that is not limited to a particular modelling language or application scenario and that at the same time is able to identify exact pattern matches. Moreover, to be beneficial such an approach has to return results with good performance. By providing a statistically rigorous performance evaluation, this paper can therefore be seen as a continuation of the work of [De10]. 3 Set-Theory Based Pattern Matching 3.1 Research Design Our research follows the design science approach [He04] and more specifically the design science research methodology put forth by [Pe07]. Design science is concerned with the creation of innovative artefacts solving previously unsolved problems. In our case the artefact constitutes a generic pattern matching algorithm that is able to find structures in conceptual models created in arbitrary modelling languages. The methodology of [Pe07] stipulates six steps for the process of conducting design science, namely problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication. In this paper, we conduct a statistically rigorous performance evaluation of the artefact presented by [De10]. We assess its capability of efficiently contributing to the analysis of conceptual models. In an additional development iteration we augment the artefact to include a caching algorithm that further improves performance. 3.2 Pattern Matching Approach The idea of this approach is to apply set operations to a set of model elements, representing the model to be analysed. Based on graph theory, the approach recognizes any conceptual model as a graph G, consisting of vertices V and edges E, where G=(V,E) with E$V×V. Therefore, the approach distinguishes model objects, representing nodes, and model relationships, representing edges, interrelating model objects. Starting from a particular basic set, the approach searches for pattern matches by performing set operations on this basic set. We define the set O of all objects, the set R of all relationships, and the set E = O ! R to be the basic sets required for this approach. By combining different set operations, patterns are built up successively. Given a pattern definition, the matching process returns a set of model subsets representing the pattern matches found. Every match found is put into a separate subset. In the following, we introduce the available operations of the approach briefly. A detailed formal specification can be found in [De10]. 81 Each operation has a defined number of input sets and returns a resulting set. In the explanation of the operations, we use additional sets (X: arbitrary set of elements; Y: arbitrary set of objects; Z: arbitrary set of relationships) specifying which kinds of inputs an operation expects. " ElementsOfType(X,a) returns a set of all elements of X, belonging to the given element type a. " ElementsWithTypeAttributeOfValue(X,a,b) returns a set of all elements of X whose type is assigned an attribute a. In addition, the instance of the type attribute has to be of value b. A type attribute might be the label of an element. The function then returns all elements having a particular label b. In order to assemble complex pattern structures successively, the following operations combine elements and their relationships and elements being related, respectively: " ElementsWith{In|Out}Relations(X,Z) returns a set of sets containing all elements of X and their {ingoing | outgoing} relationships of Z. " ElementsDirectlyRelated(X1,X2) returns a set of sets containing all elements of X1 and X2 that are connected directly via undirected relationships of R, including these relationships. Each inner set contains one occurrence. " DirectSuccessors(X1,X2) is the directed analogue to ElementsDirectlyRelated. A further category of operation is needed to build patterns representing recursive structures (e.g. a path of arbitrary length): " {Directed}Paths(X1,Xn) returns a set of sets containing all sequences with undirected {directed} relationships, leading from any element of X1 to any element of Xn. The elements that are part of the paths do not necessarily have to be elements of X1 or Xn, but can also be of E\X1\Xn. Each path found is represented by an inner set. " {Directed}Loops(X) is defined analogously to {Directed}Paths. It returns a set of sets containing all undirected {directed} sequences, which lead from any element of X to itself. To avoid infinite sets, only finite paths and loops are returned. To provide a convenient specification environment for structural model patterns, we define some additional functions that are derived from those already introduced: " ElementsWith{In|Out}RelationsOfType(X,Z,c) returns a set of sets containing all elements of X and their {undirected} directed, {incoming | outgoing} relationships of Z of the type c. Each occurrence is represented by an inner set. " ElementsWithNumberOf{In|Out}Relations(X,n) returns a set of sets containing all elements of X, which are connected to the given number n of {undirected} directed {incoming | outgoing} relationships of R, including these relationships. Each occurrence is represented by an inner set. " ElementsWithNumberOf{In|Out}RelationsOfType(X,c,n) returns a set of sets containing all elements of X, which are connected to the given number n of {undirected} directed {incoming | outgoing} relationships of R of the type c, including these relationships. Each occurrence is represented by an inner set. 82 " {Directed}PathsContainingElements(X1,Xn,Xc) returns a set of sets containing elements that represent all undirected {directed} paths from elements of X1 to elements of Xn, which each contain at least one element of Xc. The elements that are part of the paths do not necessarily have to be elements of X 1 or Xn, but can also be of E\X1\Xn. Each such path found is represented by an inner set. " {Directed}PathsNotContainingElements(X1,Xn,Xc) is defined analogously to {Directed}PathsContainingElements. However, it returns only paths that do not contain any element of Xc. " {Directed}Loops{Not}ContainingElements(X,Xc) is defined analogously to {Directed}Paths{Not}ContainingElements. " {Longest|Shortest}{Directed}Path{Not}ContainingElements(X 1,Xn,Xc) is defined analogously to {Directed}Paths{Not}ContainingElements. However, the function only returns the shortest or longest paths from elements of X 1 to elements of Xn containing or not containing at least one element of Xc. By nesting the functions introduced above, it is possible to build structural model patterns successively. The results of each function can be reused adopting them as an input for other functions. In order to combine different results, the basic set operators union (!), intersection (#), and complement (\) can generally be used. Since it should be possible to not only combine sets of pattern matches (i.e., sets of sets), but also the pattern matches themselves (this refers to the inner sets), the approach incorporates additional set operators. These operate on the inner sets of two sets of sets respectively. The Join operator performs a union operation on each inner set of the first set with each inner set of the second set having at least one element in common. The InnerIntersection operator intersects each inner set of the first set with each inner set of the second set. The InnerComplement operator applies a complement operation to each inner set of the first outer set combined with each inner set of the second outer set. Only inner sets that have at least one element in common are considered. As most of the set operations introduced expect simple sets of elements as inputs, further operators are introduced that turn sets of sets into simple sets. The SelfUnion operator merges all inner sets of one set of sets into a single set performing a union operation on all inner sets. The SelfIntersection operator performs an intersection operation on all inner sets of a set of sets successively. The result is a set containing elements that each occur in all inner sets of the original outer set. DirectSuccessors(ElementsOfType(O, Function),ElementsOfType(O, Event)) The example of an EPC pattern given above illustrates the application of the approach. This pattern represents all functions that are directly succeeded by an event. The ElementsOfType calls return the set of all functions and events respectively. They take the basic set O as input which represents the set of all objects contained in the model to be searched. The second parameter specifies the type of the objects contained in the intermediate result sets. These are then passed on to the DirectSuccessors call returning a set of sets. Each inner set contains a function, the succeeding event and the edge between these two objects. 83 Figure 1 illustrates the prototypical implementation of the approach as a plugin for a meta-modelling tool. The patterns are defined in a specification environment that is integrated into the meta-modelling environment of the tool. The modelling environment allows for executing the pattern matching algorithm. All elements that belong to a particular pattern match are highlighted. In the example presented in Figure 1 two pattern matches were found. Each match consists of a function, its succeeding event and the relationship between these two objects. Pattern specification environment First match Second match Figure 1: Application of the pattern matching approach 3.3 Extensions of the approach Our approach is implemented using the visitor design pattern known from software engineering [Ga95]. A nested pattern definition is represented as a search tree. The algorithm performs a depth-first search on that tree calculating the result of the leaf nodes first and then returning this intermediate result to the next higher level of the tree. This structure allows for efficiently caching intermediate results, since a given sub-tree may appear multiple times within one pattern definition. Before calculating the result on any given level in the search tree, the algorithm checks a hash table to see if the given subtree has already been calculated. This hash table can be read in constant time, thus allowing for extremely fast access. 84 4 Performance Evaluation 4.1 Model Base As model base, we chose 19 different EPC models that were available from two previous research projects in the fields of public administration (nine models) [Be05] and the retail industry (ten models) [BS04]. In terms of the former, the largest process model contains 343 elements and describes the process of refunding student travel expenses. The smallest model consists of 26 elements and depicts the application for a dog licence fee. As far as the process models of the retail industry are concerned, the largest model contains 150 elements and depicts the process of goods receipt. The smallest model consists of 20 elements representing the return of empties. In terms of the structure of the models, in both model pools the large models contain a disproportionately high number of split-connectors. We chose these model pools for two reasons. First, these processes were surveyed in real life scenarios. Consequently, they allow us to test the pattern matching approach in a realistic context. Second, these pools explicitly include very small process models having a minimum of 20 elements as well as extremely large models of up to 343 elements. This range of different model sizes allows us to evaluate the scaling characteristics of the pattern matching approach. We argue that, other than the complexity of the pattern and the abovementioned structure of the model, the size of the model is the factor that most influences runtime performance. Additionally, we argue that most conceptual models exhibit model sizes that fall into the range we cover here. We therefore conclude that the results we obtained for EPC models are also representative of other process modelling languages as well as application domains. 4.2 Patterns In total we searched for seven patterns in each of the 19 process models. All but one pattern check the syntactical correctness of EPCs. Although the matching approach can be used in a variety of scenarios, we restrict ourselves to syntactical soundness checking as this task requires the most complex patterns. Furthermore, the patterns we searched for are based on the workflow patterns presented by [Va03] and common syntactical errors in EPCs described by [Me07]. The first pattern we searched for is the “AND might not get control from XOR/OR” (AND)-pattern reported in [Me07]. It returns paths of arbitrary length that begin in an XOR/OR-split and end in an AND-join which is the successor of an event having no incoming edges. The exact definition of that pattern is given below. Another very common syntactical error in EPCs constitutes a decision split after an event (DSAE) [Me07]. Other than that, we also searched for the syntactically correct version of that pattern, the decision split after a function (DSAF). The exact pattern definitions can be found in [De10]. Furthermore, we searched for connector loops (CL) which are paths of arbitrary length that start and end in the same element and contain only connectors. 85 DirectedPaths( COMPLEMENT( UNION(ElementsOfType(O,'OR'),ElementsOfType(O,'XOR')), UNION( SELFUNION(INNERINTERSECT(UNION(ElementsOfType(O,'OR'), ElementsOfType(O,'XOR')),ElementsWithNumberOfOutRelations( UNION(ElementsOfType(O,'OR')ElementsOfType(O,'XOR')),1))) SELFUNION(INNERINTERSECT(UNION(ElementsOfType(O,'OR'), ElementsOfType(O,'XOR')),ElementsWithNumberOfOutRelations( UNION(ElementsOfType(O,'OR'),ElementsOfType(O,'XOR')),0))) )), INNERINTERSECT(ElementsOfType(O,AND),DirectSuccessors( ElementsWithNumberOfInRelations(ElementsOfType(O,'Event'),0), ElementsOfType(O,'AND')))) We determined the longest sequence of activities (LSA) in each model which we define as the longest paths not containing connectors. Additionally, we checked if every XORsplit is joined by the appropriate counterpart XOR (XOR) [Me07]. This pattern returns all paths from XOR-split connectors to XOR-join connectors not containing AND- or OR-join connectors. We also searched for all paths not containing elements that have a particular label (PRC). We define this pattern to calculate all paths from the start to the end elements of the model. From this set of paths we subtract all paths that do contain elements having that particular label. This second set of paths is calculated by joining the set of paths from all start to all end elements with the set of elements exhibiting the label. By defining the pattern in this manner, we calculate the paths from all start to all end elements twice. In doing so, we are able to demonstrate the effect of the caching mechanism on a computationally expensive operation like a path search. For reasons of brevity we omit the exact definitions of the CL-, LSA-, XOR-, and PRC-patterns here. 4.3 Evaluation Process To obtain the performance data in a statistically rigorous manner, we applied the steadystate performance methodology presented by [GBE07]. The methodology was developed to control measurement errors in Java programs caused by the non-deterministic execution in the virtual machine due to garbage collection, just-in-time (JIT) compilation and adaptive optimisation. As described above, the pattern matching approach was implemented as a plugin for a meta-modelling tool written in C#. This programming language suffers from the same measurements errors. Therefore we adapted the approach of [GBE07] to C#. To compensate for the non-deterministic behaviour of the virtual machine, we chose the so-called steady-state performance measurement determining program performance after JIT compilation and optimisation. The performance evaluation was conducted on an Intel® Core™ 2 Duo CPU E8400 3.0 GHZ with 3.25 GB RAM and Windows 7 (32-Bit edition). We disabled the energy saving settings in Windows and executed the process as a real-time process to avoid any unnecessary hardware slow down or process switching. Prior to each search run a complete garbage collection was forced. In doing so, we further eliminate systematic errors. For the time measurement we used the high resolution QueryPerformanceCounter-API in Windows in concert with the adapted methodology. 86 During the initial warm-up phase, the JIT compiler optimized the pattern search algorithm. This implies running the algorithm until the variation coefficient drops under two per cent [GBE07]. This coefficient is calculated by dividing the standard deviation of all runs by its mean execution time. This led to searching each pattern in each model at least five times. Once this warm-up phase was completed and a steady state was reached, the measurement phase started. During this phase, each pattern was searched in each model ten times. After ten search runs, the meta-modelling tool was restarted triggering another ten search runs. This process was repeated 35 times to compensate for the non-deterministic behaviour of the virtual machine [GBE07]. For each process, the mean execution times were determined for each combination of pattern and model with caching enabled and disabled respectively. This leads to a total of 70 measurements per combination of pattern and model, 35 for caching enabled and 35 for caching disabled. 4.4 Performance Data We first consider the original algorithm without the caching extension. Runtime measurements are depicted in Figure 2. Each model is represented on the abscissa by its number of elements. In each model all seven patterns were searched for resulting in one bar for each pattern. The ordinate represents the time unit in milliseconds on a logarithmic scale. Each measurement depicts the mean execution time of all 35 search processes. In addition, each measurement exhibits a confidence interval smaller than one per cent given a confidence level of 99 per cent. 1000000 100000 10000 Milliseconds 1000 100 10 1 0,1 0,01 343 150 142 121 104 89 79 67 67 61 57 50 50 46 42 35 26 24 20 Number of elements LSA CL XOR PRC AND DSAE DSAF Figure 2: Performance evaluation of the original algorithm Figure 2 demonstrates that the majority of patterns are found within less than one millisecond. In all but six cases results were obtained in considerably less than one second. The data suggest that our pattern matching algorithm returns results with an overall acceptable performance. Furthermore, the figure suggests that the performance of the matching algorithm depends on three factors, namely the size and the structure of the model (cf. Section 4.1) as well as the complexity of the pattern. The latter refers to what and how many functions and operators are used in the pattern definition and to what extent they are nested. Since the measurements are right-skewed, Figure 2 shows that the larger the model the longer takes the matching process. 87 The structure of the model refers to its number of split-connectors. A linear sequence of elements can be more efficiently searched than a highly branched model. This explains the execution times observed in the third largest model representing a procurement process in the retail industry. This process model contains a large number of splitting XOR connectors, thus prolonging the matching process. In terms of the pattern complexity, in all but one model the LSA pattern took the longest to compute. Furthermore, identifying events or functions that are followed by an XOR-split connector can be computed in less than one millisecond in all models except the largest one. The interaction of these three factors influences runtime performance. Although overall performance is acceptable, Figure 2 indicates that in case of large, highly branched models in combination with complex patterns the execution time increases exponentially. This is especially the case if path functions are used in the pattern definition. As explained in Section 3.2 these functions determine all paths from all start to all target elements. Depending on the number of objects in a given model in combination with the number of their relationships, an exponential number of paths have to be calculated. This theoretical complexity explains the execution times of the LSA and PRC patterns in the large, highly branched models. The exponential increase in runtime performance motivates augmenting the original matching approach to include a caching mechanism that stores previously calculated sub patterns. The execution times of the augmented algorithm are depicted in Figure 3 and Figure 4. Each figure depicts runtime performance of only one pattern, namely the PRC pattern in Figure 3 and the XOR pattern in Figure 4. The models are again represented on the abscissa by their number of elements. The figures depict two measurements for each model, one with caching enabled and one with caching disabled. The execution times of the original algorithm without the caching mechanism are taken as a reference value for the measurements of the extended version. Again, the measurements represent the mean value of all 35 search processes. Figure 3 suggests that the caching mechanism improves the overall search performance in every model. It represents measurements for the PRC pattern that allows for caching a computationally expensive path search (cf. Section 4.2). The data suggest that the caching mechanism works particularly well on large and highly branched models in combination with complex patterns allowing to cache expensive operations. In the five largest models the execution time decreased by approximately 50 per cent. Given this pattern, the performance gain tends to decrease with the size of the model. For the smallest model only a 20 per cent gain was measured. The fact that the caching mechanism improves performance particularly well for computationally expensive operations is also supported by Figure 4. Here the execution times of the XOR pattern are compared. This pattern only allows for caching relatively cheap calls to the ElementsOfType function. The expensive path search is performed only once. In this case, the caching mechanism yields hardly any performance increase in large models. For smaller models, however, execution times can be decreased by up to 25 per cent. Since in models of up to 100 elements this pattern can be searched for in less than one millisecond anyway, the actual performance gain is negligible. Still, the data presented in Figure 4 indicates that execution times decrease in all but two models. 88 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 343 150 142 121 104 89 79 67 67 61 Without caching 57 50 50 46 42 35 26 24 20 With caching Figure 3: Comparison of the caching algorithm to the original algorithm executing the PRC pattern These performance statistics prove that although our pattern matching algorithm is generic and not optimized to suit a particular application scenario it returns results with acceptable performance. The caching extension further decreases execution time. Its performance gain depends on the size and structure of the models to be searched as well as the complexity of the patterns. It is particularly beneficial on large, highly branched models in combination with patterns that contain computationally expensive operations like the path search. In those cases, the caching mechanism increases runtime performance by up to fifty per cent. In the worst case, caching previously calculated sub-patterns does not yield any performance gain. As expected, however, it does not decrease execution time either. 100% 80% 60% 40% 20% 0% 343 150 142 121 104 89 79 67 67 Without caching 61 57 50 50 46 42 35 26 24 20 With caching Figure 4: Comparison of the caching algorithm to the original algorithm executing the XOR pattern 89 5 Summary and Outlook In this paper, we conduct a statistically rigorous performance evaluation of a generic settheory based pattern matching approach. On the basis of a literature review we conclude that there is no generic pattern matching approach suited for any application scenario that at the same time is able to identify structures in conceptual models of arbitrary modelling languages. To prove that such a generic approach is beneficial in terms of performance, a detailed analysis of its runtime behaviour is required. After briefly introducing the matching approach, we augmented the algorithm by a caching mechanism that stores previously calculated sub-patterns. We introduced the model base as well as the patterns we used to conduct the evaluation. Since the size of the models we analysed ranges from 20 to 343 elements, we argue that the results we obtained are also representative of other process modelling languages as well as application scenarios. The evaluation process was conducted according the methodology presented by [GBE07]. Our results were therefore obtained in a statistically rigorous manner. The performance data suggest that despite its generic nature our pattern matching approach returns results with acceptable performance. Most of the patterns could be identified within a few milliseconds. The caching mechanism we introduce continues to decrease execution time by up to fifty per cent. Having conducted a statistical analysis of its runtime behaviour, future research activities will focus on a theoretical performance evaluation of the matching approach to determine the complexity class of the algorithm. To confront the exponential increase in execution time given large, highly branched models in combination with complex patterns, we furthermore intent to introduce an additional function called ElementsOfTypeFast. This function will work on a similar basis than the caching mechanism presented in this paper. It will access a data structure that holds all elements of the respective element types of a given modelling language. This data structure will furthermore allow for access in constant time. The idea is to fill this data structure only once before the actual calculation of the pattern matches. ElementsOfTypeFast will then call this structure and thus return all elements of a particular type in constant time which will lead to a further increase in execution time. References [Au05] Aumueller, D. et. al.: Schema and Ontology Matching with COMA++. In: Proc. of the 2005 ACM SIGMOD Int. conf. on Management of data, Baltimore, 2005; pp. 906-908. [AVW08] Alves de Medeiros, A.K.; van der Aalst, W.M.P.; Weijters, A.J.M.M.: Quantifying Process Equivalence Based on Observed Behavior. Data & Knowledge Engineering 64, 2008; pp. 55-74. [Aw07] Awad, A.: BPMN-Q: A Language to Query Business Processes. In (Reichert, M., Strecker, S., Turowski, K. Eds.): Proc. of the 2nd Int. Workshop on Enterprise Modelling and Information Systems Architectures, St. Goar, 2007; pp. 115-128. [Be05] Becker, J. et. al.: Referenzmodellierung in öffentlichen Verwaltungen am Beispiel des prozessorientierten Reorganisationsprojekts Regio@KomM. In (Ferstl, O. K.; Sinz, E. J.; Eckert, S.; Isselhorst, T. Eds.): Wirtschaftsinformatik 2005, Physica-Verlag HD, Heidelberg, 2005; pp. 729-745. 90 Becker, J.; Schütte, R.: Handelsinformationssysteme. 2nd edition, Redline, Frankfurt, 2004. [DDG09] Dijkman, R. M., Dumas, M., García-Bañuelos, L.: Process Model Similarity Search. In (Dayal, U., Eder, J., Koehler, J., Reijers, H. A. Eds.): Proc. of the 7th Int. Conf. on Business Process Management, Ulm, 2009; pp. 48-63. [De10] Delfmann, P. et. al.: Pattern Specification and Matching in Conceptual Models. A Generic Approach Based on Set Operations. In: Enterprise Modelling and Information Systems Architectures 5, 2010; pp. 24-43. [DHY08] Dong, X. L.; Halevy, A.; Yu, C.: Data Integration with Uncertainty. In: Proc. of the 33rd Int. Conf. on Very large data bases, Vienna, 2008; pp. 687-698. [Di09] Dijkman, R. et. al.: Aligning Business Process Models. In: Proc. of the 13th IEEE Int. Conf. on Enterprise Distributed Object Computing, Auckland, 2009; pp. 40-48. [Di10] Dijkman, R. et. al.: Similarity of Business Process Models. Metrics and Evaluation. In: Information Systems 36, 2010; pp. 498—516. [DK07] Delfmann, P.; Knackstedt, R.: Towards Tool Support for Information Model Variant Management – A Design Science Approach. In: Proc. of the 15th European Conf. on Information Systems, St. Gallen, 2007; pp. 2098-2109. [EKO07] Ehrig, M., Koschmider, A. Oberweis, A.: Measuring similarity between semantic business process models. In (Roddick, J.F., Hinze, A. Eds.): Proc. of the 4th Asia-Pacific Conf. on Conceptual Modelling, Ballarat, 2007; pp. 71–80. [Fa09] Fahland, D. et. al.: Instantaneous Soundness Checking of Industrial Business Process Models. In (Dayal, U., Eder, J., Koehler, J., Reijers, H. A. Eds.): Proc. of the 7th Int. Conf. of Business Process Management, Ulm, 2009; pp. 278-293. [Ga95] Gamma, E. et. al.: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam, 1995. [GBE07] Georges, A., Buytaert, D., Eeckhout, L.: Statistically rigorous java performance evaluation. ACM SIGPLAN Notices, vol. 42, 2007; pp. 57-76. [Gr05] Grossmann, G. et. al.: Behavior based integration of composite business processes. In (van der Aalst, W.M.P., Benatallah, B., Casati, F. Curbera, F. Eds.): Proc. of the 3rd Int. Conf. on Business Process Management, Nancy, 2005; pp. 186-204. [He04] Hevner, A. R. et. al.: Design Science in Information Systems Research. MIS Quarterly 28, 2004; pp. 75-105. [Kü08] Küster, J. et. al.: Detecting and Resolving Process Model Differences in the Absence of a Change Log. In (Dumas, M., Reichert, M., Ming-Chien, S. Eds.): Proc. of the 6th Int. Conf. on Business Process Management, Milan, 2008; pp. 244-260. [Kn10] Knuplesch, D. et. al.: On Enabling Data-Aware Compliance Checking of Business Process Models. In (Parsons, J., Saeki, M., Shoval, P., Woo, C. C., Wand, Y. Eds.): Proc. of the 29th Conf. on Conceptual Modeling, Vancouver, 2010; pp. 332-346. [La10] La Rosa, M.et. al.: Merging Business Process Models. In (Meersmann, R., Dillon, T., Herrero, H. Eds.): Proc. of the 2010 Int. Conf. on the move to meaningful internet systems, Hersonissos, 2010; pp. 96-113. [Me07] Mendling, J.: Detection and Prediction of Errors in EPC Business Process Models. Doctoral Thesis, Vienna University of Economics and Business Administration. Vienna, 2007. [Pe07] Peffers, K. et. al.: A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems 24, 2007; pp. 45-77. [PS11] Po, L.; Sorrentino, S.: Automatic generation of probabilistic relationships for improving schema matching. Information Systems 36, 2011; pp. 192-208. [RB01] Rahm, E.; Bernstein, P. A.: A survey of approaches to automatic schema matching. The Very Large Data Base Journal 10, 2001; pp. 334-350. [RS10] Rajesh, A.; Srivatsa, S. K.: XML Schema Matching – Using Structural Information. International Journal of Computer Applications 8, 2010; pp. 34-41. [BS04] 91 [Sc00] [SDH08] [SM07a] [SM07b] [Sm09] [Sm10] [TC06] [UC04] [Va03] [VAW06] [VDM08] [VTM08] [WDM10] [We10] [We11] [WHM08] [YDG10] Scheer, A.-W.: ARIS – Business Process Modelling. 3rd edition, Springer, Berlin, 2000. Sarma, A.; Dong, X.; Halevy, A.: Bootstrapping Pay-As-You-Go Data Integration Systems. In: Proc. of the 2008 ACM SIGMOD Int. Conf. on Management of data, Vancouver, 2008; pp. 861-874. Simon, C., Mendling, J.: Integration of Conceptual Process Models by the Example of Event-driven Process Chains. In Proc. of the 8th Int. Tagung Wirtschaftsinformatik, Karlsruhe, 2007; pp. 677-694. Simon, C., Mendling, J.: Integration of Conceptual Process Models by the Example of Event-driven Process Chains. In (Oberweis, A., Weinhardt, C., Gimpel, H., Koschmider, A., Pankratius, V., Schnizler, B. Eds.): Proc. of the 8th Int. Tagung Wirtschaftsinformatik, Karlsruhe, 2007; pp. 677-694. Smirnow, S. et. al.: Action Patterns in Business Process Models. In (Baresi, L., ChiHung, C., Suzuki, J. Eds.): Proc. of the 7th Int. Conf. on Service-Oriented Computing, Stockholm, 2009; pp. 115-129. Smirnov, S. et. al.: Meronymy-Based Aggregation of Activities in Business Process Models. In (Parsons, J., Saeki, M., Shoval, P., Woo, C. C., Wand, Y. Eds.): Proc. of the 29th Int. Conf. on Conceptual modelling, Vancouver, 2010; pp. 1-14. Tansalarak, N.; Claypool, K.T.: QMatch – Using paths to match XML schemas. Data & Knowledge Engineering 60, 2006; pp. 260-282. Uchitel, S., Chechik, M.: Merging Partial Behavioural Models. SIGSOFT Software Engineering Notes 29, 2004; pp. 43-52. Van der Aalst, W. et. al.: Workflow Patterns. Distributed and parallel databases 14, 2003; pp. 5-51. van der Aalst, W. M. P., Alves de Medeiros, A. K., Weijters, A. J. M. M.: Process Equivalence: Comparing Two Process Models Based on Observed Behavior. In (Dustdar, S., Fiadeiro, J.L., Sheth, A. Eds.): Proc. of the 4th Int. Conf. on Business Process Management, Vienna, 2006; pp. 129-144. van Dongen, B., Dijkman, R., Mendling, J.: Measuring Similarity between Business Process Models. In (Bellahsène, Z., Léonard, M. Eds.): Advanced Information Systems Engineering, LNCS 5074, Heidelberg, 2008; pp. 450-464. Vergidis, K., Tiwari, A., Majeed, B.: Business process analysis and optimization: beyond reengineering. IEEE Transactions on Systems, Man, and Cybernetics 3, 2008; pp. 69–82. Weidlich, M., Dijkman, R., Mendling, J.: The ICoP Framework. Identification of Correspondences between Process Models. In: (Pernici, B. Eds.): Proc. of the 22nd Conf. on Advanced Information Systems Engineering, Hammamet, 2010; pp. 483-498. Weidlich, M. et. al.: Process Compliance Measurement based on Behavioral Profiles. In (Pernici, B. Ed.): Proc. of the 22nd Conference on Advanced Information Systems Engineering, Hammamet, 2010; pp. 499-514. Weber, B. et. al.: Refactoring large process model repositories. Computers in Industry 62, 2011; pp. 467-486. Weber, I., Hoffmann, J., Mendling, J.: Semantic Business Process Validation. In (Hepp, M., Stojanovic, N., Hinkelmann, K., Karagiannis, D., Klein, R. Eds.): Proc. of the 3rd Int. Workshop on Semantic Business Process Management, Tenerife, 2008; pp. 22-36. Yan, Z.; Dijkman, R.; Grefen, P.: Fast business process similarity search with featurebased similarity estimation. In (Meersmann, R., Dillon, T., Herrero, H. Eds.): Proc. of the 2010 Int. Conf. on the move to meaningful internet systems, Hersonissos, 2010; pp. 60-77. 92 Some Guidelines for the Conception of Domain-Specific Modelling Languages Ulrich Frank Information Systems and Enterprise Modelling University of Duisburg-Essen ulrich.frank@uni-due.de Abstract: While the potential prospects of domain-specific modelling languages (DSML) are undisputed, the design of a DSML faces specific challenges that have raised only little attention so far. They relate to the boundaries between a DSML and corresponding models as well as to the question how specific a DSML should be. Addressing these challenges does not only contribute to the development of meta modelling methods, it also relates to judging the economics of a DSML. This paper suggests guidelines to support typical decisions that occur with the design of a DSML. They mainly concern the level of abstraction a potential language concept should be defined on. The guidelines are not intended to serve as recipes for design, but rather to improve the transparency of design decisions. 1. Motivation In recent years, the conception of domain-specific modelling languages (DSML) has gained increasing attention. This is for comprehensible reasons: A general purpose modelling language (GPML) provides modellers with rudimentary concepts such as ‘Class’, ‘Attribute’ etc. only. Different from that, a DSML includes higher level concepts that are reconstructions of technical terms in the targeted domain, e.g. ‘Organisational Unit’, ‘Business Process’, ‘Strategic Resource’ etc. Therefore, the modeller is not forced to specify these high level terms on his own. Instead he may reuse the concepts of the DSML. This will not only promote modelling productivity. It also contributes to model quality: Different from a GPML, the concepts of a DSML include implicit integrity constraints that prevent the construction of nonsensical models. Furthermore, it should be expected that the concepts of a DSML are developed with specific expertise and care. Also, a DSML will typically feature a specific graphical notation that should foster comprehensibility of respective models. The small, simplified example in Figure 1 illustrates the benefits of DSML compared to GPML. The prospects of deploying DSMLs are contrasted with remarkable challenges. They concern both, the economics of DSMLs and their development as well as principal considerations of language design. Against this background, it is remarkable that there is hardly any method for guiding the development of modelling languages in general, the design of DSML in particular. Wand’s and Weber’s approach to evaluate the quality of modelling languages by referring to ontological categories [WaWe93] does not help much with the specification of a DSML in general, nor with differentiating levels of abstraction in particular. Take, 93 for instance, the construct “ontological completeness”: Depending on the purpose of a DSML, completeness in this sense may be not relevant. Work on modelling language design is usually focusing on formal features of meta modelling languages or on meta modelling tools (e.g. [Jeus07], [JaSz06]). Since a modelling method consists of at least one modelling language and a corresponding process model, one would assume that work on method engineering has produced support for the development of modelling languages. Figure 1: Illustration of DSML in comparison to GPML However, this is not the case. While there is a plethora of approaches on method engineering (e.g. [Brin96], [Roll09], for an overview see [HeRa10]), they mainly focus on the construction and configuration of process models and take the modelling language as given. Recent publications on DSML such as [Klep08] and [KeTo08] describe the construction and use of DSMLs, but do not go into the details of meta model design. The current lack of support may be attributed to the fact that those who develop modelling languages are usually highly specialized experts. However, that does not mean that they are not in need for support, since the design of modelling languages can be an extremely demanding task. For several years, an essential part of our research has been directed towards the development of domain-specific modelling languages and corresponding modelling methods. During this time we have faced numerous challenges that are related to certain recurring design decisions and to peculiarities of the development process. Many discussions with various designers of modelling languages have shown that we share this experience with others. This may be regarded as a deluxe problem that is relevant for a few only. However, the lack of substantiated guidance increases the risk of poorly designed modelling languages, which will eventually affect all prospective language users. With the increasing popularity of DSML and corresponding model-based approaches to software development, this problem becomes even more crucial. While a number of tools support the specification of DSML and the 94 realisation of corresponding model editors, prospective users can expect only little guidance with designing a language that fits its purpose. This paper is intended to suggest guidelines for supporting design decisions that are specific to the development of DSML. For this purpose, it addresses mainly three aspects: scope and economics, differentiating between language and language application and dealing with abstraction conflicts. The background of this research is work on languages for enterprise modelling. Nevertheless, the results should be applicable to DSML in other areas as well. 2. Scope and Economics of DSML Usually, the decision for developing a DSML will require some sort of economic justification. The costs for developing – and maybe distributing – a DSML should not exceed the additional benefit to be expected from its deployment. Unfortunately, development costs and benefits are hard to judge in advance. If a DSML is developed for one particular project only (as recommended e.g. by [KeTo08]), it may be possible to estimate the expected cost/benefit ratio in a seemingly satisfactory way. However, as soon as the development costs require a higher scale of reuse, the decision whether a DSML will pay off or not will be of remarkable complexity and contingency. It seems reasonable to assume that – ceteris paribus – the development costs will be the higher, the more elaborate and specific a language is, i.e. the more semantics (in the sense of information content) its concepts incorporate. However, the effect of semantics on a DSML’s benefit is ambivalent. On the one hand, semantics should promote modelling productivity and model quality, hence the benefit of reuse in a particular case. On the other hand, semantics will compromise the scale of reuse: The more specific a DSML is, the fewer the number of cases it can be applied to. Note, however, that trying to determine an optimal level of semantics would be a hopeless undertaking: Not only that measuring the level of semantics provided by a DSML on a metric scale is hardly possible, the benefits of additional semantics will be hard to judge in a single case – not to speak of numerous cases with considerable variance. Despite these obstacles, it is nevertheless required to make corresponding decisions, namely to determine whether or not to develop a DSML for a certain domain – and how specific it should be. At the same time, there is need for reducing the costs and risks related to the development of a DSML. Due to the contingency of the subject, deciding on the scope and economics of a DSML in advance needs to account for specific aspects of a particular case. Hence, the following criteria serve as general guidelines only that need to be interpreted against the background of a particular project. To outline the scope of the targeted DSML, modelling projects can be categorized with respect to modelling subject and purpose, complexity and frequency. The higher the complexity and frequency of modelling a certain subject for certain purposes, the higher the benefit to be expected from a respective DSML. Also, the prospective users’ attitude and skills need to be accounted for. If they are reluctant or even reject the idea of a DSML, a negative impact on economics can be expected. To develop an elaborate idea of the benefits to be expected from a DSML, a thorough requirements analysis is 95 mandatory. Unfortunately, analyzing the requirements a DSML should satisfy is a particular challenge. Often, prospective users will not be familiar with the idea of a DSML and, hence, will not know what they can expect from such an artefact. Our experience in developing DSML suggests that it is a promising approach to develop prototypical diagrams for certain analysis scenarios, e.g. the economic analysis of an IT infrastructure (see [Fran10]). Against this background, one can conduct a high-level assessment of benefits with respect to certain classes of modelling tasks and corresponding users. To evaluate prospective economics, costs and risks of introducing, using and maintaining the DSML need to be addressed. This requires accounting for the availability of development tools, the qualification of developers and users as well as the volatility of requirements to be expected in future times. Sometimes, the availability of a DSML will enable additional options such as the integration with other DSML or the use of models at run time. With respect to evaluating the investment into the development of a DSML, these options should be taken into account. Even if the economic perspective of a DSML seems to be promising, its feasibility may still be a challenge – especially if no previous experiences with similar projects exist. In these cases, it may be a good idea to start with a smaller scale project. 3. Differentiating between Language and Language Application In general, a domain-specific modelling language is aimed at providing its prospective users with technical terms suited to describe the targeted domain. However, sometimes it is not evident, whether a concept should be part of the language specification or instead be defined through the language. To illustrate this problem, it is useful to clarify the targeted level of abstraction. The quest for abstraction suggests to not represent instances – for a good reason: Instances may change over time, which would compromise a model’s validity. On the other hand, models that represent the M2 or even higher levels of abstraction are mainly restricted to specialized applications such as the specification of modelling languages. Therefore, we focus on the M1 level, since we assume that the vast majority of conceptual models are assigned to it. As a consequence, designing a DSML requires analyzing whether a domain-level term is suited to be represented as a meta type – and therefore can be incorporated into the language – or not, which would suggest representing him in a model specified with the prospective DSML. In natural language, there is no explicit distinction between the type and the meta type level. Sometimes a term can be used on both levels and often it is used for representing instances, too. For instance: ‘Business Process’ can be instantiated into various business process types, which would qualify it as a meta type. One could argue that it could also represent a type that then could be specialized into further business process types. However, this is no option, since there is no suitable specialization concept for process types.1 ‘Organisational Unit’ can be seen as the meta type of ‘Department’, which in turn could have instances like ‘Sales Department’, ‘IT Service Group’ etc. But does ‘Sales 1 While there are a few approaches to introduce relaxed concepts of process specialization, a specialization concept that accounts for substitutability is not feasible, because it would require monotonic extensions. 96 Department’ need to represent an instance? Take for example a multi-national corporation that defines a certain organisational structure for all its national subsidiaries. In this case, ‘Sales Department’ may serve as a type. While it seems undisputed that it makes sense to model goals, it is not clear whether a goal like ‘minimize throughput time’ should be regarded as a meta type, a type or an instance. As a consequence, the respective design decisions are even more demanding: In some cases, the foundational presupposition that models are represented on the type level (M1) has to be dismissed. For example: A DSML for modelling logistic networks should include concepts to represent cities. If ‘City’ was used as a type within a particular model, the level of abstraction would usually be too high. Instead, it will often be the case that one wants to represent concrete cities, hence, particular instances in a logistic network. Table 1 illustrates the decision to be made when analyzing a term with respect to its suitability for being incorporated into a DSML. In the regular case, the decision will focus on the two alternatives in the upper row: whether a term should be represented as a meta type to become part of the language or whether it is supposed to be specified by the language. In some cases, it will be required to decide whether a term should rather be represented as a meta type or a type, where the latter implies that it is appropriate to represent instances in respective models. DSML model Meta type ‘Business Process’ Type ‘Order Management’ Type ‘Location’ Instance ‘Berlin’ Table 1: Language vs. language application on different levels of abstraction 3.1 General Criteria To develop guidelines for the above decision scenario, we will first look at criteria that need to be accounted for with every prospective language concept. Hence, we focus on the principle decision whether a term is suited to be incorporated in a language. To illustrate the criteria, we refer to examples form the domain of organisational analysis and design. Note that the following criteria do not account for the question whether a concept should be reconstructed as a type or a meta type, but only whether or not it is suited for becoming part of a DSML: a) Noteworthy level of invariant semantics: If a term can be expected to have the same meaning across all application areas a DSML is supposed to cover, it can be regarded as a candidate for being incorporated in the language. In other words: It should be possible to define the essential meaning of the concept. Essential means that the features used to specify the concept are sufficient to capture at least a minimal set of characterizing features, i.e. features that would allow for distinguishing it from other concepts. Furthermore, one should know how to describe the range of its more concrete specifications. In other words: There should be substantial knowledge about the conceptual variance the 97 abstraction covers. These aspects are related to the level of semantics, a potential language concept includes. The level of semantics corresponds to its information content: The more interpretations are excluded, the higher the level of semantics. Hence, the level of semantics depends on the semantic determination of its features, i.e. its attributes and the associated (meta) types. The level of semantics embedded in a language concept is a core indicator of its value as an abstraction: The more we know about possible instances (types or instances), the more can we express about them on an abstract level – without having to care for the peculiarities of particular instances. If the meaning of a concept changes significantly with the application context, this could be handled only with a specification on a lower level of semantics. Alternatively, it may be a reasonable decision to reduce the scope of a language, i.e. to make it more special. Hence, applying this criterion is interrelated with determining a DSML’s intended scope (see 2). Test: At first sight, it may appear that the most satisfactory approach to test an assumption about a concept’s meaning across the set of intended applications would be to conduct an elaborate and representative empirical investigation. However, such an approach faces two major drawbacks. First, it will often be not appropriate to focus on the actual meaning of a concept, but rather to pursue a semantic reconstruction that fits the purpose of the DSML. Second, for economic reasons, a comprehensive empirical investigation will usually be no option. Therefore, introspection (reflecting upon known uses of a term – which makes it empirical, too) and discursive evaluation will usually be the option of choice. In any case, the results of such a test should be regarded as a hypothesis that may still be refuted. b) Relevance: If a concept is expected to be used on a regular base, making it part of the language would increase the language’s value for most users. If it is required in rare cases only, it would increase the size of the language, hence make it more difficult to learn, while at the same time most users would not benefit from it. While this criterion is related to all other criteria, it is different in the sense that it puts explicit emphasis on the purpose of the language and the actual range of applications. Test: Creating exemplary models within the scope of intended applications helps to find out how relevant the use of the concept would be with respect to intended purposes of corresponding models. Analyzing intended applications and related purposes may suggest empirical studies. However, such an approach has its limitations: It does not seem plausible to expect a comprehensive assembly of relevant purposes from prospective users if they are not familiar with the considered kind of modelling (which will be especially the case with DSMLs that target new domains). 98 3.2 Language Concept as Meta Type or Type? In addition to determining whether a term is in principle suited to become part of a DSML, it needs to be decided whether it should be reconstructed as a meta type – which can be regarded as the regular case – or rather as a type. The first two criteria focus on checking the suitability as a meta type, while the third and fourth address the suitability as a type. c) Noteworthy semantic differences between types: From a formal point of view, a meta type should allow for a range of types with clear semantic differences. If the types that can be instantiated from the potential meta type are all too similar, the effort it takes to define the types is questionable. This criterion, too, does not only apply to the entire range of intended applications, but also to the semantic variance of types within particular models: It does not contribute to the benefit of the abstraction in a particular case, if there are no noteworthy semantic differences between potential types. Again, if the variance is noteworthy only in some cases, while in others it is not, it would indicate the contingency of a subject. Test: From a formal point of view, the meta type should allow for a range of significantly different types. That implies that the types can be defined on a high level of semantics – otherwise there would not be much chance to express clear differences between types. If this is the case, one would have to check whether there is a noteworthy number of clearly different types within the range of possible types. d) Instance as type intuitive: This criterion emphasizes language ergonomics. Would it correspond to the common use of the term to regard its instances as types? Hence, would instances be regarded as types intuitively by prospective language users or would they rather be interpreted as representing instances of the respective domain? Test: Since many people do not consciously differentiate between type and instance level in many cases, an empirical test would have to face a remarkable challenge. Therefore, referring to our Sprachgefühl (sense of language) and to its discursive evaluation will usually be the only feasible option. The following criteria serve to check whether a term that does not qualify as a meta type could instead be represented as a type offered by a DSML. e) “Instance” as abstraction: There are terms that emphasize abstractions by their very nature. Therefore, they resist against a clear distinction between the type and the instance level. For example: Is a goal such as ‘minimize throughput time of a set of business processes’ a type or rather an instance? It may be regarded as a type, since it applies to a set of processes. At the same time, it hardly allows for further instantiation. Nevertheless, it may be important to represent a corresponding goal in a model. In these cases, it is suitable to make a respective type, e.g. ‘Goal’, part of the language. 99 Test: Since there is hardly a formal criterion to guide this test, it depends chiefly on reflection and introspection to find out whether a term that does not allow for further instantiation can still be regarded as an abstraction. f) Invariant and unique instance identity: Sometimes, it makes sense to represent objects in a model that clearly qualify as instances. Examples include cities, countries or particular organisations. Apparently, these examples have in common that the respective instances have a unique identity that is relevant, i.e. it makes a difference, for the modelling purpose. Also, the features that are relevant for the modelling purpose are (widely) invariant within the intended lifetime of a model (e.g. the geographical location of a city). Therefore, including them in a model does not mean to compromise the quest for abstraction. Test: To test a term against this criterion, a number of models where it is represented as an instance need to be analyzed. The focus of the test is on the following questions: Are there useful analysis scenarios related to the intended type of models that require accounting for instances? Are these instances (widely) invariant with respect to the modelling purpose? Against this background, we suggest the following guidelines. Modelling Guideline R1: If a concept fulfils criteria a) to b), it should be considered for becoming part of the language. Modelling Guideline R2: If a concept fulfils criteria c) and d), it should be considered for being represented as meta type. Modelling Guideline R3: If a concept does not satisfy guideline R2 and fulfils either criterion e) or f), it should be considered for being represented as type. To illustrate the use of the suggested criteria, we consider three terms selected from the examples discussed above. The following tables show the result of evaluating them against the criteria of the modelling guidelines. “+” indicates that the term clearly fulfils the corresponding criterion. Organisational Unit An organisational unit is a part of an organisation that reflects a permanent principle of the division of labour. An organisational unit may contain other organisational units. a) invariant semantics + The term is used on a high level of abstraction. The essence of its semantics should not vary substantially. b) relevance This is a key term for describing organisation structures. + c) variance of type semantics + The semantics of types of organisational units can vary significantly. d) instance as type intuitive + At least some of the potential instances will be regarded c as types almost intuitively, e.g. “Department”, “Division”. Other potential instances, such as “Marketing Department”, “Consumer Electronics Division”, will probably not be regarded as types by many. Hence, the final assessment of this criterion depends on the recommended instantiation. 100 “o” expresses that it fulfils the criterion to a satisfactory degree, while “-“ indicates that it fails to satisfy the corresponding criterion. “c” means that – with respect to the considered criterion – the use of the term is contingent, i.e. in some cases it fulfils the criterion, in others it does not. Note that guidelines R2 and R3 are considered only, if guideline R1 applies. R3 is relevant only, if R2 does not apply. Note that there are no precise guidelines based on “hard facts” for evaluating domain terms against the suggested criteria. Instead, it is recommended to make use of discursive evaluation that is aimed at developing reasons that are regarded as convincing by the participants. Apparently, the term ‘Organisational Unit’ qualifies as language concept to be represented as a meta type. Nevertheless, it may be an option to include a more specific term in a DSML, e.g. ‘Department’: It may be regarded as a relevant term of the corresponding technical language and since it is more specific than ‘Organisational Unit’ it could increase a DSML’s contribution to productivity and integrity. Department A department is an organisational unit, which will usually include further organisational units. It may be part of a superordinate organisational unit. a) invariant semantics b) relevance As the description of the term indicates, there is not much that is specific to the term department, which would clearly distinguish it from the more general term organisational unit. Even on a high level of abstraction, the meaning of the term varies. In some cases, a department will be part of a superordinate head department or a division, in other cases not. This term is frequently used for describing organisation structures. c + Since criterion a) is not satisfied, guideline R1 does not apply to ‘Department’. Therefore, testing it against guidelines R2 and R3 is obsolete. Note, however, that criterion a) is contingent, which means that for some domains the term’s semantics may be invariant (see 4.1). Location A location represents a geographical area and a corresponding settlement such as a village or a city. a) invariant semantics The essence of the term as it is outlined in the above description should not vary substantially. + b) relevance In various domains, e.g. in cross-organisational logistics, this is a key term. + c) variance of instances The semantics of instances may vary to some degree. d) instance as type intuitive It is conceivable to regard an instance as type, e.g. the type ‘City’ as opposed to the type ‘Village’. Often, however, it will be more appropriate to instantiate directly into a particular location such as ‘Berlin’ or ‘Hamburg’. 101 o o c Since guideline R2 does not clearly apply, R3 can be tested additionally. Note that in this case, it is assumed that the concept’s instances represent particular instances such as cities. e) “Instance” as abstraction If an instance is a particular location, then this criterion is not satisfied. - f) Cities, urban districts and villages satisfy this criterion without a doubt. Buildings will be regarded as invariant and unique in most applications, too. + invariant and unique instance identity The result of the last evaluation shows that ‘Location’ is suited as a language concept. The decision on the level of abstraction depends on the intended purpose. If models are supposed to represent particular locations, then the term is suited for being represented in a DSML as a type. Otherwise, a representation as meta type would be more preferable. Note, however, that there may be cases where it is required to account for both levels of abstraction (see 4). Applying the suggested guidelines to a few examples produces an ambivalent result. On the one hand, the criteria help to reduce the complexity of decisions related to the design of DSML. On the other hand, they are not easy to apply. Instead, they require a thorough and differentiated interpretation that may be regarded as arduous by some. This is especially the case for those criteria that are marked as contingent. Therefore, the guidelines need to be interpreted with respect to the intended scope and purpose of a DSML. However, scope and purpose of a DSML are sometimes hard to determine in advance. Our experience suggests that developing modelling scenarios helps to get a better idea of scope and purpose – and to dissolve the principle contingencies related to some criteria. 4. Dealing with Conflicting Levels of Abstraction The previous evaluation of the guidelines has shown that they do not always produce clear results, which requires further analysis. Sometimes, however, the results may even be partially contradictory with respect to the appropriate level of abstraction. 4.1 “Local” Types There are terms that are not perfectly suited to be incorporated into a DSML, because their semantics is not invariant within the intended language scope. Nevertheless they may be important elements of respective technical languages - and may be useful for particular applications of a DSML. For example: The semantics of the term 'Department' is not invariant across a wider range of organisations. Therefore, it seems appropriate at first to not include it in a DSML for organisation modelling. Instead, the DSML could provide the more abstract concept 'Organisational Unit', which could be instantiated into types such as ‘Marketing Department’, ‘Finance Department’ etc. However, this would not be satisfactory either, because it would not be possible to express that a marketing 102 department and a finance department (both defined on the M1 level) are two types of the same kind. To deal with these contradictory requirements, a trade-off is recommended, which is expressed in the following guideline: Modelling Guideline R4: If a term is not used consistently throughout the set of intended applications, it should not be incorporated into the language – in order to not violate modelling rule R2. However, if this term is an important part of the respective technical language and its semantics is fairly invariant within a certain application area, it can be represented as a "local type". A local type is an auxiliary abstraction that allows for adapting a DSML to specific needs. In the case of 'Department', it would enable a company to define its own conception of department. Figure 2 illustrates the specification of a local type. The local types ‘Department’ and ‘Division’ are associated to instances of ‘OrganisationalUnit’ to specify their semantics in a specific local scope. Figure 2: Illustration of „local types“ In order to protect model integrity, the local type of an organisational unit can be defined by an instance of an additional meta type (‘LocalUnitType’), which can be associated with an instance of ‘OrganisationalUnit’. ‘LocalUnitType’ provides the option to specify the hierarchical level and a characteristic designation. Furthermore, it would be possible to assign a specific graphical notation. A level is defined by a positive Integer. The lowest level, 0, is reserved for those organisational units that do not include further units and/or that do not include any position that is in command of further organisational units. If these levels are specified for all local types of organisational unit types, it is possible to enforce the constraints that they imply, e.g. that no organisational unit on level 2 can be part of a unit on level 1. The definition of a local terminology through 103 instantiations of ‘LocalUnitType’ can be regarded as defining language concepts with a limited scope, or as pseudo meta types. This approach can be further supported by supplementing a DSML with instantiations of ‘LocalUnitType’ for specific subdomains, e.g. for industrial enterprises, for public organisations, universities etc. 4.2 Intrinsic Features On the one hand, specifying a meta model requires reflecting upon the ontological essence of a term. On the other hand, it recommends taking into account that instances of a meta concept are types. Sometimes, this results in the problem that the essence of a term includes features that do not apply directly to the type level. Instead, they apply to the instances represented by a type. For example: A language for modelling business processes includes the meta type ‘BusinessProcess’, which has attributes such as ‘name’, ‘averageExecutionTime‘ and various associations to other meta types like ‘Event’, ‘OrganisationalUnit’ etc. Within a particular model, it is instantiated to a certain business process type, e.g. ‘Order Management’, which includes the instantiation of attributes from corresponding meta types. While we know that every business process instance has a particular start and termination time, these materialized features do not apply to the corresponding business process type. Since a meta type may only define features that can be instantiated to describe features of a type, it is not possible to express features that apply to the instances of this type only. However, assigning these features to every instance would not only ignore an obvious abstraction, it would also result in redundancy. This problem is well known in conceptual modelling and addressed by concepts such as “power types” [Odel98] or “clabjects” [AtKü07]. A similar concept, called "intrinsic feature" is proposed in [Fran11] to enrich a meta modelling language. A (meta) type may have (regular) attributes that apply to its instances or “intrinsic attributes” that can be instantiated only from the instances of its instances. The concept can also be applied to an entire entity type (an instance of a meta type): An entity type that must not be instantiated directly, but only on the level below the one it is presented on, is called an “intrinsic type”. Figure 3 illustrates how to specify the example concepts ‘OrganisationalUnit’ and ‘Location’ with the use of intrinsic features. Intrinsic features are marked by an ‘i’ printed white on black. Specifying e.g. ‘Location’ with intrinsic features would allow for representing both, the semantics of location types such as ‘City’, ‘Village’ etc., and respective instances. A corresponding model would include instances, e.g. ‘Hamburg’, that are characterized by a type, e.g. ‘City’, which was defined by instantiating the meta type ‘Location’. Hence, a respective model editor would need to provide modellers with two levels of abstractions. Unfortunately not every meta modelling language features concepts for specifying instance level features. But even in these cases, it is a good idea to somehow add their description to the meta model – either by comments or by marking type level features. Modelling Guideline R5: If the essential meaning of a meta type that is part of a DSML includes aspects that apply to instances of the types of the meta type and these aspects are relevant for the intended application of the DSML, then these instance level features should be included in the specification. Preferably, this should be done with meta modelling languages that feature corresponding 104 concepts. Alternatively, instance level features can be marked or added in comments. Figure 3: Example of Specification with Intrinsic Features 5. Concluding Remarks In contrast to the remarkable attention generated by the idea of DSML, there has been only little work on specific design decisions related to the conception of a DSML. While there has been some work on differentiating instance and type level features (see 4.2), questions that concern the distinction of a prospective DSML and its application have hardly been addressed so far. This is the case, too, for the decision on how specific a DSML should be. This paper has shown that these questions are essential for the development – and economics – of DSMLs and very challenging at the same time. Due to the remarkable contingency of modelling subjects and purposes, it may not come as a surprise that the proposed guidelines do not serve as recipes. Instead, their application requires a considerable effort. As a consequence, they are mainly intended to improve the transparency of design decisions and draw the reflective language designer’s attention to aspects that require further investigation. Also, they are meant to contribute to the discourse on the quality of meta models and DSML in general (see, e.g., [Fran98], [OpSe99], [FeLo03]). In addition to that, the guidelines suggest specific requirements for meta modelling languages and corresponding meta model editors that are not satisfied by most of today’s solutions. Every guideline has been motivated with respect to certain presuppositions and has been tested against a few examples. Nevertheless, there is still need for further tests and discursive evaluations, since we are only at the beginning of developing expressive methods for designing DSML. 105 6. References [AtKü08] Atkinson, C.; Kühne, T.: Reducing accidental complexity in domain models. In: Software and Systems Modelling. Vol. 7, No. 3, 2008, pp. 345-359 [Brin96] Brinkkemper, S.: Method engineering: engineering of information systems development methods and tools. In: Information and Software Technology, Vol. 38, No. 4, 1996, pp. 275–280 [DaPi+02] Dahchour, M.; Pirotte, A.; Zimányi; E.: Materialization and Its Metaclass Implementation. IEEE Transactions on Knowledge and Data Engineering Vol. 14, No. 5, pp. 1078-1094 [FeLo03] Fettke, P.; Loos, P.: Ontological evaluation of reference models using the BungeWand-Weber-model. In: Proceedings of the Ninth Americas Conference on Information Systems. Tampa, FL 2003, pp. 2944-2955 [Fran11] Frank, U.: The MEMO Meta Modelling Language (MML) and Language Architecture. 2nd Ed., ICB Research Report No. 43, University Duisburg-Essen 2011 [Fran10] Frank, U.: Outline of a Method for Designing Domain-Specific Modelling Languages. ICB-Research Report No. 42, Universität Duisburg-Essen 2010 [Fran98] Frank, U.: Evaluating Modelling Languages: Relevant Issues, Epistemological Challenges and a Preliminary Research Framework. Research Report No. 15, Institut für Wirtschaftsinformatik, Universität Koblenz-Landau 1998 [HeRa10] Henderson-Sellers, B.; Ralyté, J.: Situational Method Engineering: State-of-the-Art Review. In: Journal of Universal Computer Science, vol. 16, no. 3, 2010, pp. 424-478 [JaSz06] Jackson, E.; Sztipanovits, J.: Towards A Formal Foundation For Domain-specific Modelling Languages. In: Proceedings of the Sixth ACM International Conference on Embedded Software (EMSOFT’06), 2006, 53-63 [Jeus07] Jeusfeld, M.A.: Partial Evaluation in Meta Modelling. Proceedings of the IFIP 8.1 Working Conference on Situational Method Engineering (ME-2007), Geneva, 2007, Springer: Berlin, Heidelberg etc. 2007, pp. 115-129 [KeTo08] Kelly, S.; Tolvanen, J.-P.: Domain-Specific Modelling: Enabling full code generation. Wiley-IEEE Computer Society Press 2008 [Klep08] Kleppe, A.: Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Addison-Wesley 2008 [Odel98] Odell, J.: Power Types. In: Odell, J. (Ed.): Advanced Object-Oriented Analysis and Design Using UML. Cambridge University Press: Cambridge 1998, pp. 23-33 (revised version of: Odell, J.: Power Types. In: Journal of Object-Oriented Programming, Vol. 7, No. 2, 1994, pp. 8-12) [OpHe99] Opdahl, A.L.; Henderson-Sellers, B.: Evaluating and Improving OO Modelling Languages Using the BWW-Model. In Proceedings of the Information Systems Foundations Workshop (Ontology, Semiotics and Practice), (digital publication), Sydney 1999 [Roll09] Rolland, C.: Method Engineering: Towards Methods as Services. In: Software Process Improvement and Practice. Vol. 14, 2009, pp. 143–164 [WaWe93] Wand, Y.; Weber, R.: On the Ontological Expressiveness of Information Systems Analysis and Design Grammars. In: Journal of Information Systems, 1993, pp. 217237 106 Towards Process-oriented Information Logistics: Why Quality Dimensions of Process Information Matter∗ Bernd Michelberger1 , Bela Mutschler1 , Manfred Reichert2 1 University of Applied Sciences Ravensburg-Weingarten, Germany {bernd.michelberger; bela.mutschler}@hs-weingarten.de 2 Institute of Databases and Information Systems, University of Ulm, Germany manfred.reichert@uni-ulm.de Abstract: An increasing data overload makes it difficult to deliver needed information to knowledge-workers and decision-makers in process-oriented enterprises. The main problem is to identify information being relevant for process participants and their activities. To cope with this challenge, enterprises crave for an intelligent and processoriented information logistics. The major challenge is to provide the right process information in the right format and level of granularity at the right place and accurate point in time to the right actors. When realizing such process-oriented information logistics it becomes crucial to take into account quality dimensions of process information (e.g., completeness, topicality, punctuality). Reason is that these dimensions determine process information quality and thus also the overall relevance of process information for a particular process participant and his activities. This paper picks up this issue and analyzes different quality dimensions of process information and their impact on process-oriented information logistics. 1 Introduction Market globalization has led to massive cost pressure and increased competition for enterprises. Products and services must be developed in ever-shorter cycles and new forms of collaboration within and across organizations are continuously emerging. As examples consider product engineering processes [MHHR06] or the treatment of patients in an integrated healthcare network [LR07]. To cope with these challenges, effective business process management (BPM) [Wes07] becomes success-critical for enterprises. BPM technology has focused on the modeling, analysis, and execution of processes (e.g., using BPM systems) [MRB08] in recent years. What has been neglected so far is the support of knowledge-workers and decision-makers by providing personalized process information to them depending on their current work context. The latter determines the information a process participant needs in order to perform current and newly upcoming ∗ This research was performed in the niPRO project. This project is funded by the German Federal Ministry of Education and Research (BMBF) under grant number 17102X10. More information can be found at http://www.nipro-project.org. 107 activities. For example, to prepare his ward round a doctor needs information about his patients. Besides process-related information (e.g., the current activity), the work context also comprises device-related information (e.g., display size, bandwidth), location-based information (e.g., GPS location), and user-related information (e.g., user name, role, department). Overall, an extensive amount of process information is provided within and across organizations using techniques and tools such as e-mail, shared drives, Web 2.0 applications, and enterprise information systems [LL09]. Before characterizing the notion of process information, we first have to define the terms data and information. In literature, respective definitions are broadly diversified [Row06]. In the context of our research we apply the definitions suggested in [BCGH06, RT08, AG04]: data are raw facts or observations of things, events, activities, and transactions that are recorded and stored, but are not organized and processed, and therefore do not convey any specific meaning. Information, in turn, refers to data that has been organized and processed for a specific purpose. Consequently, it has a meaning and provides some value to the recipient. Generally, data turns into information, if someone is interested in this data. For example, a doctor might be interested in the blood group of a particular patient or the patient’s maximum and minimum body temperature during a day. Besides, information can be also derived from data. As example consider the average body temperature that can be calculated from the individual temperature data items. Consequently, the difference between data and information is not structural, but functional [Ack89]. Analogously, we define process information as follows: process information refers to data that has been processed to support process users in the modeling, execution, monitoring, optimization, and design of processes. Hence, the data gets a meaning and has a value with respect to the process users’ activities. Typical process information includes, for example, process descriptions, working guidelines, process models, operational instructions, forms, checklists, and best practices (e.g., documented in text documents, spreadsheets, presentations, and e-mails). However, the mere availability of process information is not sufficient to adequately support knowledge-workers and decision-makers in their daily activities. What enterprises need is an intelligent, process-oriented information logistics, i.e., the right process information must be provided in the right format and level of granularity at the right place and accurate point in time. More precisely, process-oriented information logistics deals with the planning, execution, and control of process information flows within or between enterprises to support knowledge-intense business processes implying human interaction and decision making [BD08]. In this paper, we address one first aspect of an effective process-oriented information logistics: quality dimensions of process information. Based on the question whether process information fulfills certain quality requirements, the overall relevance of process information can be determined. Picking up our healthcare example, typically, it becomes necessary that patient information is up-to-date and complete in order to be able to charge certain services through the accounting and billing department. Therefore, patient information which is out-of-date or incomplete is not relevant, since it cannot be processed by the medical accounting. However, depending on a specific work context, different quality dimensions might be more or less important than others. For example, for a surgeon, patient information should be available punctual and 108 up-to-date. Conversely, for an employee being responsible for patient admission, information about the patient must be complete and error-free. Therefore, depending on the work context, a different weighting of the individual quality dimensions becomes necessary. In fact, the consideration of work context and quality dimensions of process information is key to identify relevant process information. Figure 1 shows the relationship between work context and process information quality. On the one hand, the work context determines the process information a process participant needs to perform current activities. On the other hand, the use of quality dimensions allows to determine process information quality. Together, both aspects allow to determine the overall relevance of process information. Work Context task Process User task x Goal: selection of relevant (overall relevance) Process Information Quality Quality Dimension #1 Quality Dimension #2 task ... Process Information Quality Dimension #n Figure 1: Determining the relevance of process information. The presented research is performed in the niPRO project. In this project we apply semantic technology to integrate process information within intelligent, user-adequate process information portals. Our overall goal is to support knowledge-workers and decisionmakers with the needed process information depending on their current work context. So far, both research and practice do not address how processes and related process information can be effectively merged. Currently, conventional methods of information retrieval or enterprise search engines are mainly used for this purpose. Opposed to this, the niPRO process information portal aims at determining required information for knowledge-workers and decision-makers dynamically and automatically. Key challenges include the personalized provision of process information, flexible visualization of process information, and innovative design approaches for different levels of information granularity. This paper is organized as follows. Section 2 presents a running example that will be used throughout the paper. Section 3 investigates quality dimensions of process information. Section 4 discusses why contextual quality dimensions are particularly important. Section 5 discusses related work. Section 6 concludes the paper with a summary and an outlook. 2 Running Example To illustrate different quality dimensions of process information, we use a running example from the clinical domain. This example is based on experiences we gathered during an exploratory case study at a large German university hospital [MMR11]. In this case study we analyzed the process of an unplanned, stationary hospitalization, including patient admission, medical indication in the anesthesia, surgical intervention, post-surgery treatment, patient discharge, and financial accounting and management. 109 Our running example (cf. Figure 2) specifically picks up the doctor’s ward round. First, the ward round is prepared, i.e., the doctor has a look at patient information and current medical instructions (e.g., endoscope, physical therapy). Next, the doctor communicates with the patient and asks for information about his status. Afterwards, the patient is examined. This activity includes the analysis of blood values, vital values, and further follow-up diagnosis. Finally, the doctor creates medical instructions and updates patient information. ... Patient Record prepare ward round ... Notes communicate with patient ... examine patient Notes Instructions create medical instructions Notes Patient Record update patient information Figure 2: Our running example. For each of these activities different process information is needed. For example, to perform activity ”create medical instructions” a doctor needs blood values, vital values, notes, and current medical instructions. Conversely, to perform activity ”update patient information”, the doctor needs output information (e.g., notes, instructions) of other process activities and also access to the patient record. Note that the illustrated process information (e.g., notes, instructions, patient record) from our running example should be viewed only as a small part of all relevant process information. To determine which process information is relevant in a specific work context, we now take a closer look at quality dimensions of process information. This way, we can ensure that process information meets necessary quality requirements (e.g., contextual relevance, freeof-error, objectivity, and believability), fits with the work context, is suitable for specific activities, and can so be easily used by process users. 3 Process Information Quality Apart from very broad characterizations such as ”fitness for use” [TB98] there exists no commonly accepted understanding of the term information quality. In fact, giving a single definition of information quality is difficult as this term is widely used in many areas. In this paper we define process information quality as a set of quality dimensions. Process information quality can be investigated from various viewpoints, e.g., integration, transmission, security, storage, access, and representation. According to the goals of the niPRO project, we focus on the viewpoints of integration, semantic processing, and provision. Integration concerns the collection of process information from different data sources (e.g., databases, enterprise information systems, shared drives). The viewpoint semantic processing implies semantic analysis, processing and linking of process information. The provision viewpoint, finally, deals with the technical provision of process information. 110 Quality categories and quality dimensions described in the following were gathered based on a literature study, two qualitative exploratory case studies, and an additional online survey [MMR11, HMR11]. 3.1 Quality Categories of Process Information Quality dimensions of process information can be combined into different quality categories. Each category subsumes a set of dimensions. All dimensions belonging to the same category are affected by the same influencing factors such as work context (e.g., process- and user-related information) or information systems characteristics (e.g., representation of information). Specifically, we apply the classification of Wang [WS96] and Moore & Benbasat [MB91] and introduce four quality categories (cf. Figure 3): • The Intrinsic quality category (QC1) integrates self-contained quality dimensions of process information. Quality dimensions from this category are independent on the work context. Examples include believability (e.g., to improve the believability of a medical diagnosis several doctors have to approve it) and objectivity (e.g., to guarantee the objectivity the health of patients must be determined by certain criteria and not by estimation). Another example is free-of-error (e.g., to achieve error-free patient lists, name and identification number of the patient must match). Intrinsic (QC1) Accessible (QC2) Quality Categories of Process Information Representational (QC3) Contextual (QC4) independent on work context dependent on work context Figure 3: Quality categories of process information. • The Accessible quality category (QC2) combines quality dimensions being important for the access to process information. These are mainly affected by the information systems providing process information. Examples of respective quality dimensions are accessibility (e.g., to treat a patient the doctor needs the patient record) and security (e.g., ensure the security so that specific process information is only accessible to authorized users). • The Representational quality category (QC3) subsumes quality dimensions concerning the representation of process information. This quality category is again mainly influenced by the information systems providing process information. As examples of respective quality dimensions consider interpretability (e.g., the exact unit of measurement is always indicated for the given values), understandability 111 (e.g., addresses should not be displayed as GPS coordinates), consistent representation (e.g., patient information should be display consistently), and concise representation (e.g., current diseases are displayed separately from pre-existing diseases). • The Contextual quality category (QC4) integrates quality dimensions which are influenced by the work context of process users. Contextual quality dimensions are, for example, contextual relevance (e.g., a doctor performing activity ”prepare ward round” gets other process information than in activity ”create medical instructions”), completeness (e.g., patient information must be completely available), and punctuality (e.g., blood values must be available when the doctor needs it). These quality dimensions always depend on the current work context. In the next section we restrict ourselves to the contextual quality category. We do this because this quality category is particularly influenced by the work context and thus also by process-related information. 3.2 Contextual Quality Dimensions of Process Information We distinguish between nine contextual quality dimensions of process information (cf. Figure 4). Each dimension is described in the following. Contextual Quality Category (QC4) Punctuality (QD1) Topicality (QD2) Contextual Relevance (QD3) Completeness (QD4) Value-Added (QD5) Appropriate Amount (QD6) Granularity (QD7) Neighbourhood (QD8) Methods-of-Use (QD9) Figure 4: Contextual quality dimensions of process information. 3.2.1 Punctuality The Punctuality quality dimension (QD1) indicates whether process information is provided punctually when the process participant needs it. Specifically, three different time points (t) have to be distinguished: (a) the point in time at which the process user requests the process information, (b) the point in time at which the process information is provided, and (c) the point in time at which the process user applies the process information. Based on this we can determine whether process information is punctual or not. Additionally, it becomes necessary to distinguish between ad-hoc process information and regular one. The former is requested spontaneously. For example, a doctor may request blood values in order to be able to make decisions. Ad-hoc process information is accurate 112 in time if it is provided between the point in time it is requested and it is used (cf. Figure 5). The length of this period depends on the process participant. request (a) use (c) time t t+1 t+2 t+3 t+4 punctual t+5 t+6 unpunctual Figure 5: Punctuality of ad-hoc process information. Conversely, regular process information is provided at pre-defined points in time. For example, every morning a doctor may receive a patient list in order to know which patients he has to visit. The punctuality of regular process information can be distinguished between two time points: (a) punctual in respect to the provision and (b) punctual in respect to the use (cf. Figure 6). provision (b) use (c) time t t+1 t+2 t+3 punctual to the provision t+4 t+5 t+6 unpunctual punctual to the use Figure 6: Punctuality of regular process information. 3.2.2 Topicality The Topicality quality dimension (QD2) indicates whether process information captures the current characteristics (e.g., name, insurance agreement) of an object (e.g., patient) at the current point in time (t). Process information is out-of-date if the characteristics of the object have changed between the time point of capture and the time point at which the process user applies the process information (cf. Figure 7). For example, a body temperature of the patient measured two days ago is most likely obsolete. In practice, the capture of characteristics is often time-consuming. Characteristics of an object may continuously change (e.g., body temperature of a patient, health of patient). The capture can be done either in real-time (e.g., using heart rate monitor) or at pre-defined time points (e.g., during the ward round). 3.2.3 Contextual Relevance The Contextual Relevance quality dimension (QD3) indicates whether process information is relevant in a specific work context. Process information has a high contextual relevance 113 create object capture t t+1 t+2 use (1) update object t+3 t+4 up-to-date use (2) t+5 t+6 time out-of-date Figure 7: Topicality of process information. if it is needed to perform or support an activity. For example, for preparing the ward round a doctor needs current diagnoses and medical instructions. The more precise a work context can be defined the more accurate the contextual relevance can be determined. Therefore it becomes necessary to consider not only process- and user-related information, but also location-based, device-related and time information. Unlike the overall relevance (cf. Figure 1 on page 3), the contextual relevance is not influenced by other quality dimensions. As an example consider again the preparation of the ward round for which the doctor needs the patient record. Let us assume that the patient record is punctually available. In this case the patient record has high contextual relevance and high overall relevance. Let us assume that the patient record is not punctually available. In this case the contextual relevance is still high, but no overall relevance can be identified since the quality dimension punctuality is not fulfilled. 3.2.4 Completeness The quality dimension Completeness (QD4) indicates whether or not all parts of a complex process information (comprising several information parts) are available. In order to perform the activity ”create medical instructions”, for example, different blood values (together representing a process information ”blood values”) must be available. Process information is incomplete if some parts of a process information are missing. It is important to mention that completeness thereby depends on the currently needed information, i.e., it depends on the current work context. Picking up again our example, this does not mean that all possible blood values must be available, but only those being needed for current patient treatment. 3.2.5 Value-Added The Value-Added quality dimension (QD5) indicates whether it is possible to increase some ”value” (e.g., patient satisfaction, diagnostic accuracy) by using process information. For example, information about patient needs is value added because the fulfillment of the needs increases patient satisfaction. The value-added amount is calculated as the difference between the value that can be realized without using specific process information and the value that can be realized with specific process information. Figure 8 shows this 114 relationship. However it is quite difficult to determine the value-added quality dimension since respective effects often cannot be exactly estimated. without use 50% 60% use 70% 80% patient satisfaction value-added Figure 8: Value-Added of process information. 3.2.6 Appropriate Amount The quality dimension Appropriate Amount (QD6) of process information indicates whether the amount of available process information is sufficient. This is the case if the amount meets the requirements of process participants. For example, a doctor needs the name of the patient and pre-existing diseases. The appropriate amount of process information is not sufficient if he gets the entire patient record. In practice, this problem is solved by extracting process information via software (e.g., a document is divided into individual information objects). In our case studies we analyzed the appropriate amount of process information. Obviously, decision-makers are confronted with too much information. Knowledge-workers, by contrast, have the problem of being confronted with insufficient information. 3.2.7 Granularity a f c methods for aggregation 2xfindicates whether the aggregation of process The Granularity quality dimension (QD7) 1x c b meets f dthe requirements of process information users. Process information has the right granularity if immediate use is possible (cf. Figure 9). For example, if a doctor needs to know the average body temperature a patient had during the past week he should immediately get the calculated average value but not the individual values. P. Miller Day 01 02 03 04 05 Temp. 37.3 38.2 38.4 38.1 37.9 P. Miller methods for aggregation Current Temp.: 37.9 Average Temp.: 38.0 Prognosis: Figure 9: Granularity of process information. According to [Jun06], three aggregation dimensions need to be distinguished: (a) time dimension, (b) area-specific dimension, and (c) value and quantity dimension. As an example of the time dimensions consider the aggregation based on emergencies per day, 115 month, or year. Examples of the area-specific dimension include aggregation by organization units (e.g., number of patients on ward A) or patients (e.g., patients’ age and gender). As an example for the value and quantity dimension consider aggregations relating to cost centers (e.g., research and development, patient service). Unlike the granularity, the appropriate amount (QD6) meets the requirements if nonaggregated information is provided. Let us assume that the doctor wants to know the average body temperature of a patient. If individual data items are provided, only QD7 meets the requirements. If the average body temperature is provided, both QD6 and QD7 meet the requirements. 3.2.8 Neighbourhood The Neighbourhood quality dimension (QD8) indicates how strong and how frequently process information is linked to other process information. Process information which is strongly and frequently linked tends to be more important. In addition, the semantic of the relation is important. Examples include metadata-matching (e.g., author, keyword), text similarity, and usage-pattern [WM09]. Figure 10 illustrates the relations between process information along a simple example. Starting from a process information (doctor in our example) we can identify the neighbourhood being relevant. examination document patient guideline doctor Jane Doe project planning email best practices article wiki John Doe expert Figure 10: Neighbourhood of process information. 3.2.9 Methods-of-Use The Methods-of-Use quality dimension (QD9) indicates how a process participant uses the process information. Suitable use cases are, for example, to read, create, update, and delete the process information. For example, a process user cannot use read-only process information if he wants to edit process information. 4 Evaluating Quality Dimensions Quality dimensions are an important means to determine process information quality and the overall relevance of process information for a particular process participant. They are thus also an important means to realize process-oriented information logistics. 116 Generally, there exist several approaches which can be used to decide whether process information fulfills our defined quality dimensions: (a) algorithmic methods, (b) semantic technologies, (c) social methods, and (d) convergent methods. Algorithmic methods are, for example, the vector space model, the term frequency algorithm, and methods of clustering. The use of semantic technologies is another possibility to determine process information quality (e.g., via ontologies) [WM09]. Social methods include collaborative tagging or human-based rating of process information [WZY06]. Finally, convergent methods improve the aforementioned methods through their combination (e.g., algorithmic detected relationships between process information are editable by process users). Table 1 illustrates which of these methods can be used to determine our introduced quality dimensions. Table 1: Methods to determine process information quality. Shortcut Quality Dimension Algorithmic Semantic Social QD1 Punctuality x x QD2 Topicality x x QD3 Contextual Relevance x x x QD4 Completeness x x x QD5 Value-Added QD6 Appropriate Amount x x QD7 Granularity x x QD8 Neighbourhood QD9 Methods-of-Use x x x 5 Related Work Different authors investigate process-oriented information logistics in general. The stateof-the-art regarding information logistics is summarized in [DW09]. Empirical evidence on benefits generated by information logistics concepts is provided in [BD08]. Contextawareness in particular is discussed by Haselhoff [Has05] and Meisen et. al [MPVW05]. Problems of data quality and solutions for data quality improvements are described in [Red01]. Scannapieco et. Al [SVM+ 04] present an architecture for managing data quality in cooperative information system. Quality dimensions of information in general have been considered in literature. Jung [Jun06], for example, investigates data integration architectures and also sketches quality dimensions. Wang et. al [WW96, Wan98] identify aspects of data quality based on empirical research and integrate their findings into a data quality framework. Naumann et. al [NLF99] describe a framework for multidatabase query processing taking information quality into consideration. Table 2 compares our quality dimensions with the ones in the aforementioned papers. 117 Table 2: Contextual Quality Dimensions from different viewpoints. Shortcut Quality Dimension Our Paper Jung [Jun06] Wang [PLW02] Naumann [NLF99] QD1 Punctuality x x x x QD2 Topicality x x x x QD3 Contextual Relevance x QD4 Completeness x x x x QD5 Value-Added x QD6 Appropriate Amount x x QD7 Granularity x x QD8 Neighbourhood x QD9 Methods-of-Use x * Relevance x * Periodicity x * Price x x x x x x x Wang subsume QD1 and QD2 under the term timeliness. In our paper, relevance is not a separate quality dimension. Rather, relevance results from the combination of all quality dimensions. Our QD3 is not influenced by other quality dimensions (cf. Section 3.2.3 on page 7). According to Jung, the relevance can be affected by other quality dimensions (e.g., by QD1). In the paper of Wang, the influence towards the relevance is unclear. Wang et. al [PLW02] define relevance as ”the extent to which information is applicable and helpful for the task at hand”. Jung subsumed QD4 and QD6 under the term completeness. In our research the quality dimension periodicity is based on the information sources and is therefore not a quality dimension of process information. The quality dimension price can be omitted because commercial data providers are not in focus. Naumann closely follows Wang. Due to different perspectives some quality dimensions of Wang (e.g., value-added) are omitted in the paper of Naumann. 6 Summary and Outlook Enterprises are confronted with a continuously increasing data overload making it difficult for them to provide the needed information to their employees. Thereby, relevant information is often closely related to the execution of business processes. Hence, the main problem is to identify information being relevant for a process user and his activities in a given work context. To solve this problem, enterprises crave for an intelligent and processoriented information logistics enabling them to provide the right process information, in 118 the right format and level of granularity, at the right place and accurate point of time to the right people. To realize such process-oriented information logistics, quality dimensions of process information adopt a key role. This paper picks up this issue and investigates quality dimensions and discusses their role for process-oriented information logistics. Future research includes an evaluation of the proposed contextual quality dimensions with respect to the development of an intelligent, process-oriented information logistics. We will investigate the factors determining the work context of process users. Only a precise understanding of a work context allows us to accurately determine the overall relevance of process information. Future research will also pick up again Table 1 and will address the application of the discussed methods to determine our dimensions in detail. References [Ack89] R. L. Ackoff. From Data to Wisdom. in: J. of Applied Systems Analysis, 16, pp. 3-9, 1989. [AG04] E. M. Awad and H. M. Ghaziri. Knowledge Management. Dorling Kindersley, 2004. [BCGH06] P. Bocij, D. Chaffey, A. Greasley, and S. Hickie. Business Information Systems: Technology, Development and Management for the E-Business. Prentice Hall, 2006. [BD08] T. Bucher and B. Dinter. Process Orientation of Information Logistics - An Empirical Analysis to Assess Benefits, Design Factors, and Realization Approaches. in: Proc. of the 41st Annual Hawaii Int’l Conf. on System Sciences, pp. 392-402, 2008. [DW09] B. Dinter and R. Winter. Information Logistics Strategy - Analysis of Current Practices and Proposal of a Framework. in: Proc. of the 42nd Hawaii Int’l Conf. on System Sciences (HICSS-42), pp. 1-10, Hawaii, 2009. [Has05] S. Haseloff. Context Awareness in Information Logistics. PhD Thesis, Technical University of Berlin, 2005. [HMR11] M. Hipp, B. Mutschler, and M. Reichert. On the Context-aware, Personalized Delivery of Process Information: Viewpoints, Problems, and Requirements. in: Proc. of the 6th Int’l Conf. on Availability, Reliability and Security (ARES’11),Vienna, 2011. (accepted for publication). [Jun06] R. Jung. Architekturen zur Datenintegration. Deutscher Universitäts-Verlag/GWV Fachverlage GmbH, 2006. [LL09] K. Laudon and J. Laudon. Management Information Systems: Managing the Digital Firm. Pearson/Prentice Hall, 2009. [LR07] R. Lenz and M. Reichert. IT Support for Healthcare Processes - Premises, Challenges, Perspectives. in: Data and Knowledge Engineering, 61(1), pp. 39-58, 2007. [MB91] G. C. Moore and I. Benbasat. Development of an Instrument to Measure the Perceptions of Adopting an Information Technology Innovation. in: Information Systems Research, 2(3), pp. 192-222, 1991. [MHHR06] D. Müller, J. Herbst, M. Hammori, and M. Reichert. IT Support for Release Management Processes in the Automotive Industry. in: Proc. of the 4th Int’l Conf. on Business Process Management (BPM’06), pp. 368-377, Vienna, 2006. 119 [MMR11] B. Michelberger, B. Mutschler, and M. Reichert. On Handling Process Information: Results from Case Studies and a Survey. in: Proc. of the 2nd Int’l Workshop on Empirical Research in Business Process Management (ER-BPM 2011), Clermont-Ferrand, 2011. (accepted for publication). [MPVW05] U. Meissen, S. Pfennigschmidt, A. Voisard, and T. Wahnfried. Context- and SituationAwareness in Information Logistics. in: Current Trends in Database Technology EDBT 2004 Workshops, pp. 335-344, 2005. [MRB08] B. Mutschler, M. Reichert, and J. Bumiller. Unleashing the Effectiveness of Processoriented Information Systems: Problem Analysis, Critical Success Factors and Implications. IEEE Transactions on Systems, Man, and Cybernetics (SMC) - Part C, 38(3), pp. 280-291, 2008. [NLF99] F. Naumann, U. Leser, and J. C. Freytag. Quality-driven Integration of Heterogeneous Information Systems. in: Proc. of the 25th Int’l Conf. on Very Large Data Bases (VLDB’99), pp. 447-458, Edinburgh, 1999. [PLW02] L. L. Pipino, Y. W. Lee, and R. Y. Wang. Data Quality Assessment. in: Commun. of the ACM - Supporting community and building social capital CACM Homepage archive, 45 (4), pp. 211-218, 2002. [Red01] T. C. Redman. Data Quality: The Field Guide. Digital Press, 2001. [Row06] J. Rowley. The wisdom hierarchy: representations of the DIKW hierarchy. in: J. of Information Science, 33(2), pp. 163-180, 2006. [RT08] R. K. Rainer and E. Turban. Introduction to Information Systems: Supporting and Transforming Business. Wiley & Sons, 2008. [SVM+ 04] M. Scannapieco, A. Virgillito, C. Marchetti, M. Mecella, and R. Baldoni. The DaQuinCIS Architecture: a Platform for Exchanging and Improving Data Quality in Cooperative Information Systems. in: Information Systems Journal, 29(7), pp. 551-582, 2004. [TB98] G. K. Tayi and D. P. Ballou. Examining data quality. in: Commun. ACM, 41(2), pp. 54-57, 1998. [Wan98] R. Y. Wang. A Product Perspective on Total Data Quality Management. in: Commun. ACM, 41 (2), pp. 58-65, 1998. [Wes07] M. Weske. Business Process Management: Concepts, Languages, Architectures. Springer, 2007. [WM09] J. Wurzer and B. Mutschler. Bringing Semantic Technology to Practice: The iQser Approach and its Use Cases. in: Proc. of the 4th Int’l Workshop on Applications of Semantic Technologies (AST ’09), pp. 3026-3040, Lübeck, 2009. [WS96] R. Y. Wang and D. M. Strong. Beyond Accuracy: What Data Quality Means to Data Consumers. in: J. of Management Information Systems, 12(4), pp. 5-34, 1996. [WW96] Y. Wand and R. Y. Wang. Anchoring Data Quality Dimensions in Ontological Foundations. in: Commun. ACM, 39(11), pp. 86-95, 1996. [WZY06] X. Wu, L. Zhang, and Y. Yu. Exploring social annotations for the semantic web. in: Proc. of the 15th Int’l Conf. on World Wide Web (WWW ’06), pp. 417-426, 2006. 120 Towards Automated Financial Process Auditing: Aggregation and Visualization of Process Models N. Mueller-Wickop, M. Schultz, N. Gehrke, M. Nüttgens School of Business, Economics and Social Sciences University of Hamburg Max-Brauer-Allee 60 D-22765 Hamburg niels.mueller-wickop@wiso.uni-hamburg.de martin.schultz@wiso.uni-hamburg.de nick.gehrke@nordakademie.de markus.nuettgens@wiso.uni-hamburg.de Abstract: Internal and external auditors face an enormous amount of financial entries in accounting information systems. For many reasons - like legal regulations - a process-oriented view of these entries is urgently needed in order to understand the way financial entries are produced in accounting information systems and to infer the underlying processes. Traditional modeling languages focus on processes but pay no regard to the financial value-flows. Furthermore, automated process retrieval approaches only reconstruct single process instances, which need to be aggregated for reasons of comprehensibility, simplification and clearness. The paper wants to close this gap and integrate the process with the accounting perspective followed by an aggregation of single process instances. As a result we present a visualization form capable of integrating the financial view with process flows. In this way, auditors are able to trace how balance sheet items have been produced in the system during the fiscal year. 1 Introduction Current technological support for internal and external auditors is very limited. The last decade painfully shows how weakly conducted audits result in unprecedented business turbulences with corporate fraud and partly followed by collapse (years of incidents: Enron 2001; MCI WorldCom 2002; Parmalat 2003; AIG 2004; Fannie Mae 2006; Satyam 2009). Combined with the so-called “Financial Crisis” beginning in 2008 and ongoing uncertainty for the global economy, political as well as scientific focus is on the way audits are done nowadays [EU10]. Even though auditors are increasingly recognized as playing a critical role within companies, their repertoire of supporting tools and methods is out-dated. To (at least partly) remedy this deplorable state of affairs is the main objective of the paper at hand. Today’s internal and external audits focus on processes [Be97][Ru03][Ru06]. Within the bounds of process auditing an automated approach is to be developed. In this context, different aspects need to be taken into account. First, an automated approach for a 121 retrograde reconstruction of process- and value-flows from Enterprise Resource Planning (ERP) and Accounting Information Systems (AIS) must be developed. This has been done by introducing Financial Process Mining [GM10]. The automated retrieval of process instances (a process instance can be described as the representation of one execution of a business process) from system data is followed by the presentation of mined results. Modeling these results needs to fulfill different requirements for different groups of stakeholders. This paper is focused on internal and external auditors as stakeholders. Additional stakeholders include - but are not limited to - business process managers, process owners, risk managers, the board of directors and the audit committee. Both, internal and external auditors, have mainly overlapping interests. In the case of process audits an integrated view of value-flows and process flows is essential. While process flows are in the foreground, the corresponding value-flows also have to be considered in terms of risk and “materiality” (for a definition see ISA 320.3 [IFAC10]). An adequate visualization – integrating both views - has been developed and is described in chapter 4 “Related Work”. In order to gain an overall-view of the process flow including the financial flows, mined process instances need to be aggregated into process models. This paper was written to take an important step towards automated process audits. In a first step the motivation for this research problem will be explained to introduce the reader to this domain (section 2). For a further understanding the research method (section 3) as well as related work (section 4) will be presented. Following this introduction, an approach for the aggregation of financial process instances will be laid out (section 5). We conclude this paper with a summary and an outlook on work of future research in this field (section 6). 2 Motivation An integral part of a modern approach for auditing company’s financial statements is the process audit [Ru06]. This is justified by the fact that conventional auditing methods (substantive audit procedures performed for single business transactions, based on “Analytics” and “Test of Detail”) seem more and more impracticable from an efficiency point of view in a world where the number of business transactions is dramatically increasing and all data is electronically available in ERP systems. The argument behind process auditing is that all business transactions running through well designed and controlled business processes will be properly represented in the financial statements of the company [Be97] [Ru06]. Following this approach the design of the business processes including relevant controls are reviewed. Furthermore the compliance with defined processes throughout the year is checked for a sample of business transactions. The audit results are then applied to all business transactions ran through the corresponding process in the financial period under investigation. Process audits utilize interviews as means to survey the business processes of a company [Ru03]. A number of employees involved in a business process are interviewed. Based on the information gained through these interviews auditors are modeling their understanding of the actual processes including relevant controls with the help of flowcharts and/ or narratives [Ru03] (ISA 315 [IFAC10]). Software supporting the task 122 of business process survey is rarely used in current audit approaches. There are several severe issues in this approach. One is the influence of perceptions, i.e. involved individuals are only able to express their subjective perception of reality or the gained information is normative in the sense that it states what is expected to be done rather than describing the actual process [Aa02]. Secondly an auditor has to rely on the information he obtains by the employees regardless if it is potentially erroneous on purpose or unintentionally. Thirdly interviews are time-consuming and therefore come along with high costs. Last and from audit perspective the main point is that processes are not derived from the business transactions stored in ERP systems itself although the results of the process audit are applied to them later. This is the key problem our process mining approach for financial audits is aiming at. Therefore the objective is the development of an automated approach for a retrograde reconstruction of processes from business transaction data stored in ERP and AIS. Although motivated by efficiency arguments process audits are also obligate by international standards1 as they are considered as important steps for understanding the client’s business and so forming the basis for a well-founded audit of the financial statements. Starting point for this audit methodology was the introduction of the Business Risk Audit (BRA) by Bell et al. in 1997 [Be97]. BRA can be characterized as a top down audit approach starting with an analysis of the business strategy, significant business transactions and business risks of a client. Subsequently the key processes of the client are identified and analyzed regarding their conformance to business goals, handling of significant business transactions and the coverage of identified business risks. Detailed (transaction oriented) audit procedures are than effectively planned and performed based on the comprehensive knowledge gained during the previous steps. The BRA aims at focusing on audit procedures related to areas which have been identified as being exposed to high audit risks. The core idea of BRA is that a better understanding of the client’s business significantly correlates with a better understanding of the audit risks [Be97]. According to the International Standard on Auditing (ISA) 200 “The risk that the auditor expresses an inappropriate audit opinion when the financial statements are materially misstated” is defined as audit risk. Therefore an important method for focusing the audit activities on areas with a high audit risk is the concept of materiality. According to ISA 320 (Materiality in planning and performing an audit) materiality is defined as follows ”Misstatements [in the financial statements], including omissions, are considered to be material if they, individually or in the aggregate, could reasonably be expected to influence the economic decisions of users taken on the basis of the financial statements.” [IFAC10]. Consequently for each audit a materiality (quantitative and/ or qualitative measure) is to be determined by the auditor. The materiality is than applied in planning and performing an audit of the financial statements (ISA 320 [IFAC10]). The “Big Four”2 turned towards the BRA, not only for its higher efficiency (reducing the amount of substantive audit procedures and test-of-details, as mentioned above), but also 1 For instance ISA 315 states that “the auditor should obtain an understanding of the information system, including the related business processes, relevant to financial reporting ( )” ISA 315.81 [IFAC10]. 2 The “Big Four” are the four largest international accountancy and professional services firms: Ernst & Young (E&Y), Deloitte Touche Tohmatsu (Deloitte), Klynveld Peat Marwick Goerdeler (KPMG) and PricewaterhouseCoopers (PwC) 123 because of an increased value added for the client as well as a stronger link between risk management and audit [Ru06]. To support the auditors planning activities especially the decision which processes/ process variants will be subject to detailed audit procedures in due consideration of materiality our automated approach for a retrograde reconstruction of processes will not only consider the process flow itself but also integrate the corresponding value-flows. Two steps are necessary for this reconstruction task. First single business transactions which can be seen as process instances need to be reconstructed from the data stored in ERP systems. Secondly these process instances must be aggregated to infer the underlying processes/ process variants. The first step is described in [GM10]. This paper is dealing with the second step. 3 Research Method / Research problem and research methodology Following the guidelines for Design Science Research in Information Systems [He04][MS95], this paper is focused on developing a relevant IT artifact (constructs, models, methods and implementations). This artifact represents a domain-specific modeling notation and rules for aggregation of process instances constructed from financial entries stored in ERP systems. Artifacts facilitate the analysis, design, implementation and use of information systems [He04][De97]. The research idea came from the awareness of a problem that became apparent in current audit practice (inductive reasoning) regarding process audits in the context of year-end audits. Referred to [Pe07] a problem-centered approach is on hand. The research problem can be described as follows. Process audits are in fact an integral part of the audit of the financial statements of a company. However process audits are based on information not directly derived from the financial entries constituting as a whole the financial statements. Process audits are performed based on process models constructed with the help of qualitative methods of collecting data (e.g. guided interviews). Nonetheless the results of the process audit are used to develop the auditor’s opinion on the financial statements. There is a gap between the data source the audit results are based on (process audit) and the data source the audit results are applied to (financial statements). Theoretical considerations based on a literature review (deductive reasoning) helped to achieve a further understanding of the problem. Starting from this research question following objectives were derived for an artifact to be designed. There should be an automated approach for a retrograde reconstruction of process instances and corresponding value-flows from financial entries stored in ERP systems. Furthermore, there should be a modeling notation representing the reconstructed process instances and aggregation rules to infer a generalized view on all process instances constituting the financial statements. In this paper a BPMN-based notation capable of integrating the financial view with the process flows is proposed. In [GM10] an algorithm is described for reconstructing process instances from financial entries. Based on this, aggregation rules for process instances are developed. These rules were developed with individual sample process instances from a standard SAP IDES system and are presented as narratives. 124 4 Related Work 4.1 Financial Process Mining Financial Process Mining is a subset of the Process Mining family in which all kind of process, control, data, organizational and social structures are discovered in log files or other data stored in information systems [Aa11]. According to van Dongen and van der Aalst the goal of Process Mining is the construction of “a formal model describing a set of real life executions” [DA05]. By now, the research field of Process Mining as a whole is a fairly well researched. The first research was done in 1995 by Cook and Wolf for the software engineering process [CW95]. In 1998, process mining was adapted to Workflow Systems by Agrawal and Gunopulos [AGL98]. A full overview until 2002 is given by van der Aalst et al. in [Aa02]. Up to now most of the Process Mining techniques have been developed for event log data stored in different kind of information systems (e.g. workflow management systems, ERP or AIS) and therefore focusing on process flow reconstruction [Ra06]. Most research in this domain focuses on heuristics based algorithms searching for an order of relations between events in event logs [Me03]. Recent approaches like decision mining and social network/ organizational mining tend to broaden the considered data sources [RV06][VS04]. However, data of financial entries stored in ERP systems instead of using event logs as data source is not yet considered. In [GM10] an algorithm is described which mines financial entries and reconstructs the corresponding process instances by using information from the open item accounting. These process instances are the basis for the aggregation and inference of the underlying process models described in this paper. A number of approaches for aggregating resp. merging process instances are suggested in literature. [Ro10] provide an algorithm that produces a single configurable process model encompassing the behavior of the input models. [GVJ08] use an abstraction called functional graph to merge event driven process chains. [SKY06] define four types of merge (sequential, parallel, conditional, and iterative) and describe corresponding algorithms for performing the merge operations. [LCW09] describe a heuristic algorithm to construct a generic process model from process variants which minimizes the average distance between the generic model and the process variants. [DDA06] offer three algorithms for discovering process models from process runs which differ regarding the information contained in these runs. In [DA05] a multi-step approach for inferring an overall process model from single processes instances is suggested. Moreover frameworks for comparing different merge approaches and for merging incomplete and inconsistent graph-based views are presented in [Br06] and [SE06]. However, these approaches do not fulfill the requirements from an audit perspective outlined in section 5.1 Data source, Requirements and Illustration. 4.2 Modeling Languages - BPMN(-Finance) At present, there is a broad variety of different process modeling languages in research and practice. The main representatives are the Business Process Modeling Notation (BPMN) [BPMI04] and the Event Driven Process Chain (EPC) [SN95][SN00] [KNS92]. Other modeling languages include the Integrated Definition (IDEF) [MM06] [KBS10], 125 Petri Nets [Pe62] and the Unified M Modeling Lan nguage (UML L) [OMG10] [Ru04]. In uages, see e.g. [Za01] [KLL L09]. addition thhere are further scientific moodeling langu Considerinng the objectiv ve of this papper only a mod deling languag ge capable off integrating the financiial- and process-dimension is appropriatee. Subsequenttly a notation is proposed to depict financial pro ocess instancees including value flows using BPM MN. For an S was chossen as test ER RP System. Th herefore all pro roperties are evaluation see [LK06]. SAP w their SAP terms. The BPMN-Finan nce notation described below w will later displayed with be used forr an illustrativ ve example off the aggregation algorithm. B BPMN-Finan nce BPMN activities aree business actiivities. In SAP P these are im mplemented I this examp ple the transaaction name as transsactions or suubprograms. In (Autom matic Paymennt), the userr who carrieed out the transaction (OLBE ERT), the acttual transactiion code (F1 110) and thee document numberr which wass created when w the transaction wass executed (200000 00531) are shhown. It is posssible to add any a data of thee document header. Moreover, it is feasiblee to mark trransactions rrepresenting control activities by ccolor coding them t . Events are items onn accounts. The T first num mber represent nts the item ment (001), th he number beelow indicatess the actual numberr of the docum amountt which was pposted to the account (3.14 41 €). In adddition to the conventional BPMN N meaning (staart-, intermed diate- and endd-event) the color off an event hass a meaning: Blue Yellow The item has been pposted to a baalance sheet acccount on thee asset side. m an addittional asset haas been posteed or a liabilitty has been This means compen nsated (= Debbit). The iteem has been pposted to a balance b sheet account on tthe liability side. Th his means an additional liaability has beeen posted or aan asset has been co ompensated (= = Credit). Green The item m is an incom me posting (= Debit, D Profit & Loss is affeccted). Red The item m is an expennse entry (= Crredit, Profit & Loss is affeccted). BPMN sequence floows connect activities, a gateeways and evvents. Their n is to speccify the process flow in BPMN moddels. In the function proposeed notation thhe sequence flows f connectt transactions (activities) and iteems on accouunts (events). The processs flow does not always reflect the t chronologgical order of the t processing g in an ERP syystem (here in SAP P). For a bettter understand ding our notaation depicts the logical order of events and aactivities. Ano other advantag ge of this apprroach is the ndence of a pparticular ER RP system, ass different syystems may indepen have deeviant internall processing lo ogic. Regardless of the pprocess flow w, a connectio on between an activity (transacction) and an event (item) indicates thatt the item wass posted by 126 this traansaction. Acttivities within n accounts (ssee below) coonstitute an exception. They reprresent a clearring of open items. i Includiing them is i technically possible posinng a risk of necessaary as a manuual execution is incorrecct assignmentt. Edges betw ween events deepict the assiggnment of a clearing g item and thee correspondin ng cleared item m. BPMN groups repre sent accountss in BPMN-Finance. In the top middle the acccount numberr and the acccount name is shown. Thee design is following conventioonal accountin ng practice. By B coloring tthe account i open-iteem managed aaccounts are indicated. Orange The fin nancial accounnt is not involv ved in open iteem accountingg. Black Financiial account is iinvolved in op pen item accounting. Table 1: BPMN N-Finance mod deling elements 5 The Fiinancial Process Data Aggregation (FPDA)) Algorithm m 5.1 Data source, Requiirements and Illustration Process innstances recon nstructed from m financial entries e can be b described as directed graphs. Nodes N are cllassified in two fundam mentally diffeerent groups:: activities (transactions in SAP) an nd events (iteems in SAP). Items are gro ouped into acccounts. In a simplified representation of a processs instance acccounts are deepicted as a nnode, not a m. These two groups are ddifferentiated by b their propeerties. Each aaccount and single item each transaaction can be included more re than once in n the same pro ocess instancee. A process instance sttarts and endss with 1-n acccounts. Accounts are linkeed by transacctions. Each transactionn can be linkeed to 2-n accoounts. Accoun nts cannot be linked l directlyy with each other. The linkage is dep picted by edgges representin ng the processs flow within the process P instan nces include no cycles ressp. can be reepresented as an acyclic instance. Process directed grraph. Reason is i that the linkkage between n transactions and accounts is based on financial entries. e A finaancial entry caannot be posteed twice, therre are uniquelyy identified by their doocument numb ber in the ERP P systems. From a daata perspective following ccan be stated:: for inferring g the aggregat ated process model the data source is i globally coomplete. Conssidering the domain d of finaancial audit od (e.g. fiscal year) is relevaant. Hence theere are a finitee number of only a certtain time perio relevant finnancial entriees which can bbe determined d in the ERP system and uused for the aggregation. Provided that the used ERP system fulfills generaally accepted accounting principles the t source datta is free from m noise. For the agggregation alg gorithm follow wing requirem ments can be specified froom an audit perspectivee: Completenness: Each pro ocess sequencee being part of o the process instances whiich are used for the agggregation need d to be includded in the aggrregated process model. In tthis context sequence means m a possib ble way in a pprocess instancce (graph). 127 Rationale: An auditor has to give an opinion on the financial statements as a whole. Hence, the method of materiality would suggest reducing the aggregated processes model to process sequences with a value flow on or above materiality level. But auditors are obliged to apply also qualitative materiality measures and are forced to put specific attention to sources for material misstatements (e.g. accounting errors, fraud) (ISA 240, ISA 320, [IFAC10]). Therefore rare or abnormal process sequences are potentially of high interest for the auditor’s opinion. No new process sequences: Exclusively process sequences included in the process instances which are used for the aggregation should be incorporated in the aggregated process model. Rationale: As described above only a certain time period (in most cases a fiscal year) with finite number of financial entries is relevant from an audit perspective. The aggregated process model should only contain process sequences at least one financial entry can be associated with. Otherwise the process sequence was not executed in real world and is therefore not relevant for the audit. No cycles: The aggregation algorithm should not create cycles. Rationale: As the process instances are acyclic itself the aggregated process model should also be acyclic to reflect the characteristics of the underlying process instances and consequently the characteristics of the underlying financial entries. Given the requirements listed above algorithms mentioned in the literature can be evaluated regarding their applicability. As said before the focus of most research in the domain of process mining is on heuristics based algorithms. Statistical and heuristic approaches do not necessarily ensure completeness as certain sequences in the process instances may have a low probability and therefore remain undetected [Me03]. In addition, as the data source in the domain of financial processes is globally complete purely algorithmic approaches seem to be more appropriate [CW98][SKY06][Ro10] [GVJ08][DA05][DDA06][Me04]. However, these approaches either create cycles in or add additional behavior (new process sequences which are not included in the input process instances) to the aggregated process models. As explained above these are undesired properties in our use case. Therefore we present a new aggregation algorithm. It operates with process instances reconstructed according to the mining algorithm introduced in [GM10]. For demonstration purposes a payment run instance and a manual payment instance were chosen and simplified. The automatic payment run has three generic activities: 1. “Receive goods”, 2. “Receive invoice” and 3. “Pay invoice”. The actual mined process instance had 26 “Post Goods Receipt for PO” transactions and 26 corresponding “Post invoice document” transactions. Out of these 26 concurrent process flows, two were randomly chosen. The manual payment instance has the same three generic activities. However, for the 3rd activity a different SAP transaction was used. The used accounts are also the same besides two Accounts: “400100 - Purchase Raw M.” and “305000 Packaging Material” The basic process instances look like the following (please note the sequence flow from the right to the left), see Figure 1: 128 Figure 1: Initial process instances (22 accounts; a 10 transactions) 5.2 Definin ng start and end e events Start- and end-events e (ittems) need to meet at least one o of the folllowing two coonditions: 1. The account theey are posted to is not involved in open-iitem-accountinng m 2. There is no cleaaring-documeent for this item 129 For all ideentified itemss (e.g. debit iitem) meeting g one of thesse conditions it is to be determinedd whether theey are start- or end-eventts. This is done by exam mining their offsetting item i (e.g. cred dit item). If thhis offsetting item cleared an a item the seelected item is an end-eevent. On the contrary, if thhe offsetting item i got clearred the selecteed item is a start-eventt. By applying g this rule all start- and end-events are identified i andd marked as such. 5.3 Definin ng internal, start s and end d nodes for the algorithm All accounnts either exclusively contaaining items which are ideentified as staart- or endevents are marked as staart or end noddes depending on their items. All other acccounts and a marked as a process moodel internal nodes disting guished by thheir names. activities are Accounts are a named aft fter their accouunt names, acctivities are named n after thheir activity names. For demonnstration reasons a genericc model of th he payment run r instance ddepicted in Figure 1 iss created. Accounts are reppresented by nodes named d with capital letters and activities / SAP transacttions are repreesented by nodes named wiith numbers. T The generic F 2 repressents the abovve presented model. m Green nodes n are start rt nodes, red model in Figure nodes are end e nodes and d yellow node s are internal nodes. Figure 22: Generic proceess model 5.4 Perforrm the aggreg gation Apply rule no1: All iden ntical start andd end nodes are merged. Merging accounts a is do one by insertiing all items to one combiined account.. In general activities are a also unitted straight aaway. Please note that so ome transactioon specific information could be lost l when meerging activitties, e.g. the user who exxecuted the ocess model inn Figure 3 illu ustrates this steep: activity. Thhe generic pro 130 Figure 3: Generic G processs model after merging m start and d end nodes After mergging all start and end noddes the algoriithm identifies all possiblee sequences from start to end nodes. When referrring to sequen nces a possiblle way from a start to an end node is meant. Apply rulee no2: All ideentical sequennces (includin ng the predecessor sequencces of each node) begiinning from th he start nodes are merged. Each identtified sequencce starting from m a start nodee is compared d to all other ssequences the longest possible maatch between each pair is marked for merger m if all ppredecessor a identical. T The generic sequences of each node included in thhe two selecteed sequences are process moodel in Figure 4 illustrates tthis step: Figurre 4: Generic prrocess model affter applying rule no2 v node sequences annd therefore In theory, a complex prrocess model would have various c to be comparred would be enormous. e Forr real world the possiblle number of combinations data we did not experience this as a problem. Sophisticated S process instannces which result in a great number of comparisoons were very rare. Apply rule no3: All iden ntical sequencees (including the successor sequences off each node) f the startt and end nodees are merged d. beginning from First the allgorithm comp pares all identtified sequencces beginning with a start nnode to each other. The longest matcch between eaach sequence is marked forr merger if alll successor a identical. This step is sequences of each node included in thhe two selecteed sequences are del in Figure 5 illustrates thhis step: repeated foor all end notees. The genericc process mod Figurre 5: Generic prrocess model affter applying rule no3 131 Transform ming the abovee shown geneeric process model m back in n the originall format we obtain thee process mo odel presentedd in Figure 6. As you can see a cconsiderable simplificattion of the orriginal processs instances is achieved. Never N the lesss all initial process innstances are fully includeed and no new n process sequences aare created. Furthermore, it is evideent that a purrchase of raw w material (acccount “4001000 Purchase ment (activity y/ SAP transaaction FB01 Raw M.”) is always acccompanied byy manual paym M Schultz. O On the other hand, a purch hase of invenntory goods "Post docuument") by Mr. always com mes along with h an automatiic payment run n. Fig gure 6: Aggregaated process moodel (11 accoun nts; 6 activities / SAP transactioons) 6 Summary and Fu uture Work k In this papper we have provided an approach for the visualizaation and agggregation of process innstances extraacted from E ERP systems or AIS. The developmen ent and the demonstrattion were based on SAP ass a well-know wn and widely y-used ERP syystem. With this approaach two goalss have been acchieved. Firsttly, process flows and valuue-flows are integrated in a notation (BPMN-Finannce). Secondlly, rules for th he aggregationn of process w provided d to infer a leess complex process p model representing all process instances were instances considering c au udit requirem ments. The visu ualization of financial proccesses shall help externnal and intern nal auditors too shift their viiew towards financial f proccesses: from financial statements being a set of iteems on accou unts to a process-oriented pperspective. ns which proccesses and pro ocedures produ uced the finanncial entries This perspective explain fore the financcial statementts throughout the fiscal year. Using an appropriate and therefo notation annd aggregation this processs view aims at a a better and d faster underrstanding of the interdeependencies and a procedurees within the accounting function f by aallowing an easier cognnitive processsing. Future w work will inclu ude research in the area off rule based abstractionn and documen nt property orriented visualization. The underllying project for f this articlee is funded by y the BMBF (G German Federral Ministry of Educattion and Research) andd supervised by PT-DL LR (project references: 01IS100411B). 132 References [Aa02] Van der Aalst, W. M. P. et al.: Workflow Mining: a Survey of Issues and Approaches, Beta: Research School for Operations Management/ Logistics, Working Paper 74, 2002 [Aa11] Van der Aalst, W. M. P.: Process Mining: Discovery, Conformance and Enhancement of Business Processes, Springer Verlag, Berlin, 2011 [AGL98] Agrawal, R.; Gunopulos, D.; Leymann, F.: Mining Process Models from Workflow Logs, Advances in Database Technology - EDBT'98. Springer Berlin, Volume 1377/1998.page 469, 1998. [Be97] Bell, T. B.et al.: Auditing organizations through a strategic-systems lens, University of Illinois at Urbana-Champaign, KPMG Peat Marwick LLP, 1997 [BPMI04] BPMI (Business Process Management Initiative): Business Process Modeling Notation (BPMN) http://www.bpmn.org/Documents/BPMN_V1-0_May_3_2004.pdf .retrieved 25.02.2010, 2004 [Br06] Brunet, G. et. al.: A manifesto for model merging. Proceedings of the 2006 international workshop on Global integrated model management, ACM (2006), 5–12. [CW95] Cook, J. E.; Wolf, A. L.: Automating Process Discovery through Event-Data Analysis, Proceedings of the 17thinternational conference on Software engineering, Seattle, pp. 73 – 82, 1995 [CW98] Cook, Jonathan E.; Wolf, Alexander L.: Discovering models of software processes from event-based data, ACM Transactions on Software Engineering Methodology, 7 (3), pp. 215-249, 1998 [DA05] Van Dongen, B.F.; van der Aalst, W.M.P.:Multi-phase Process mining: Aggregating Instance Graphs into EPCs and Petri Nets, 2nd International Workshop on Applications of Petri Nets to Coordination. Workflow and Business Process Management (PNCWB). ICATPN 2005 [DDA06]Van Dongen, B.F.; Desel, J.; van der Aalst, W.M.P.: Aggregating Causal Runs into Workflow nets, BETA Working Paper Series, WP 173, Eindhoven University of Technology, 2006 [De97] Denning, P. J.: A new social contract for research. Communications of the ACM. Volume 40 Issue 2. Feb. 1997, 1997 [EU10] European commission, Green Paper - Audit Policy: Lessons from the Crisis http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0561:FIN:EN:PDF retrieved 12.06.2011, 2010 [GM10] Gehrke, N.; Mueller-Wickop, N.: Basic Principles of Financial Process Mining: A Journey through Financial Data in Accounting Information Systems. In: Proceedings of the 16th Americas Conference on Information Systems, Lima, Peru, 2010 [GVJ08] Gottschalk, F.; Aalst, W.M.P.; Jansen-Vullers, M.H.: Merging Event-Driven Process Chains. In: (R. Meersman, Z. Tari) On the Move to Meaningful Internet Systems: OTM 2008. Springer Berlin Heidelberg, Berlin, Heidelberg, 2008, pp. 418-426. [He04] Hevner, A. R. et al.: Design Science in Information Systems Research. In: MIS Quarterly 28(1), pp. 75-105, 2004 [IFAC10] International Federation of Accountants (IFAC): 2010 Handbook of International Quality Control, Auditing, Review, Other Assurance, and Related Services Pronouncements Part I, ISBN 978-1-60815-052-6, 2010 [KBS10] Knowledge Based Systems, Inc (KBSI): All IDEF Method Reports (KBSI) http://www.idef.com/Downloads.htm retrieved 02.August 2010, 2010 [KLL09] Ko, R.K.L.; Lee, S.S.G; Lee, E. W.: Business process management (BPM) standards: a survey, Business Process Management Journal. Vol. 15.Iss: 5. pp.744 – 791, 2009 [KNS92] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten (EPK). Technical Report. Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), 1992 133 [LCW09]Li, C.; Reichert, M.; Wombacher, A.: Discovering Reference Models by Mining Process Variants Using a Heuristic Approach. In, (U. Dayal, J. Eder, J. Koehler and H.A. Reijers): Business Process Management. Springer Berlin Heidelberg, 2009, pp. 344-362. [LK06] List, B.; Korherr, B.: An evaluation of conceptual business process modeling languages. Proceeding SAC 06. Proceedings of the ACM symposium on Applied computing, 2006 [Me03] Medeiros, A.K.A. de; van der Aalst, W.M.P.; Weijters, A.J.M.M.: Workflow Mining: Current Status and Future Directions In R. Meersman et al. (Eds.): CoopIS/DOA/ODBASE 2003, LNCS 2888, pp. 389–406, 2003. Springer-Verlag Berlin Heidelberg 2003 [Me04] Medeiros, A.K.A de; van Dongen, B.F.; van der Aalst, W.M.P.; Weijters, A.J.M.M.: Process Mining: Extending the alpha-algorithm to Mine Short Loops. BETA Working Paper Series, WP 113, Eindhoven University of Technology, Eindhoven, 2004 [MM06] Menzel, C.; Mayer, R.J.: The IDEF Family of Languages. Springer. Berlin, 2006 [MS95] March, S.; Smith, G. F.: Design and natural science research on information technology. Decision Support Systems. Volume 15. Issue 4. December 1995. pp. 251-266, 1995 [OMG10] Object Management Group (OMG). OMG Unified Modeling Language (OMG UML), Infrastructure. Version 2.3, http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/ retrieved 02.August 2010, 2010 [Pe07] Peffers, K; Tuunanen, Z.; Rothenberger, M. A.; Chatterjee, S.: A Design Science Research Methodology for Information Systems Research, Journal of Management Information Systems, Issue: Volume 24, Number 3, Pages: 45 – 77, 2007 [Pe62] Petri, C. A.: Kommunikation mit Automaten, Darmstadt, T. H., F. f. Math. u. Physik, Diss. v. 20. Juni 1962 (Nicht f. d. Aust.) III, p. 128, 1962 [Ra06] Ramesh, A. (2006). Process Mining in PeopleSoft. Master's Thesis. Technische Universiteit Eindhoven. Eindhoven. The Netherlands http://prom.win.tue.nl/research/wiki/blogs/pub2006/process_mining_in_peoplesoft [Ro10] Rosa, M. et. al.: Merging Business Process Models. In (R. Meersman, T. Dillon und P. Herrero): On the Move to Meaningful Internet Systems: OTM 2010. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, pp. 96-113. [Ru03] Russell, J.P.: The Process Auditing Techniques Guide: A Pocket Guide. ASQ Quality Press, Milwaukee, 2003 [Ru04] Rumpe, B.: Modellierung mit UML. Berlin/Heidelberg. Springer. XIII, 2004 [Ru06] Ruhnke, Klaus: Business Risk Audits: State of the Art und Entwicklungsperspektiven, Journal für Betriebswirtschaft, 56 (4), pp. 189-218, 2006 [RV06] Rozinat, A.; van der Aalst, W.M.P.: Decision Mining in Business Processes in BETA Working Paper Series, WP 164, Eindhoven University of Technology, Eindhoven, 2006 [SE06] Sabetzadeh, M.; Easterbrook, S.: View merging in the presence of incompleteness and inconsistency. Requirements Engineering 11, 3 (2006), pp. 174-193. [SKY06] Sun, S.; Kumar, A.; Yen, J.: Merging workflows: A new perspective on connecting business processes. Decision Support Systems 42, 2 (2006), pp. 844-858. [SN00] Scheer, A.-W.; Nüttgens, M.: ARIS Architecture and Reference Models for Business Process Management. Business Process Management. Springer. Berlin / Heidelberg, pp. 301-304, 2000 [SN95] Scheer, A.-W.; Nüttgens, M.: Business Process (Re-) Engineering: Architecture, Reference Models and Toolset, Kasprzak, T. (Ed.) Information Technologies in Business Reengineering, Uniwerytet Warszawski, Studia Informatyki Gospodarczej. Warschau. pp. 31-39, 1995 [VS04] van der Aalst, W.; Song, M.: Mining Social Networks: Uncovering Interaction Patterns in Business Processes. In Business Process Management, Lecture Notes in Computer Science, pp. 244-260, Springer Berlin / Heidelberg, 2004 [Za01] Zamli, K. Z.: Process Modeling Languages: A Literature Review, Malaysian Journal of Computer Science, 14 (2), pp. 26-37, 2001 134 A Reference Architecture for Semantic Content Management Systems Fabian Christ, Benjamin Nagel s-lab - Software Quality Lab University of Paderborn Warburger Str. 100 D-33098 Paderborn fchrist@s-lab.upb.de bnagel@s-lab.upb.de Abstract: Content Management Systems (CMS) lack the ability of managing semantic information that is part of the content stored in a CMS. On the other hand, a lot of research has been done in the field of Information Extraction (IE) and Information Retrieval (IR), respectively. Additionally, the vision of the Semantic Web yields to new software components that make semantic technology usable for application developers. In this paper, we combine IE/IR concepts with the technologies of the Semantic Web and propose a new family of CMS, called Semantic CMS (SCMS), with advanced semantic capabilities. We provide a reference architecture for SCMS and prove its value along two implementations. One implementation was created as part of the Interactive Knowledge Stack research project and another one in a one-year student project exploring the design of an SCMS for the software engineering domain. 1 Introduction The growing importance of an efficient content management is omnipresent in nearly each aspect of daily business. The challenges posed by the raising amount of content are wellknown [AL99] and are becoming greater due to the high availability of content from various sources like the Internet. Through this, more and more unstructured content needs to be handled and therefore aggravate the management of content by Content Management Systems (CMS). Addressing these challenges, the “Semantic Web Wave” [LHL01] brought up several technologies that enable the definition of semantics as machine-readable metadata, termed “semantic metadata”. Recent approaches [Sar08], like named-entity recognition, clustering and classification use the foundations and facilitate the automatic enrichment of content with semantic metadata. The semantic metadata allow the automatic structuring This work has been part-funded by the European Commission under grant agreement FP7-ICT-2007-3/ No. 231527 (IKS - Interactive Knowledge Stack). 135 Presentation & Interaction Semantic Lifting Knowledge Representation & Reasoning Persistence Figure 1: The four layers of an SCMS and thereby the further processing like searching or filtering. In addition, these metadata enable the reasoning of new knowledge based on the content. Summarizing the research trends of the last years, several technological foundations and algorithms have been developed to face the challenges of efficient content and knowledge management. On the other hand, only little attention has been paid to the integration of these approaches from a software engineering perspective. The integration of semantic functionalities has significant impact on the architecture. The CMS architecture has to be extended in comparison to traditional CMS, because the storage and processing of semantic metadata in a semantic CMS (SCMS) needs to be considered. Furthermore, concepts for reasoning and knowledge extraction need to be integrated and the controlling of their processing must be handled. The authors participate in the Interactive Knowledge Stack (IKS)1 project, that is focused on building an open and flexible technology platform for SCMS. As a working hypothesis, when starting the project in 2009, we thought of four layers, shown in Figure 1, that would be required to have in an SCMS architecture. The top layer called Presentation & Interaction for presenting knowledge to the end user and support a direct interaction with this knowledge. To extract knowledge from content the second layer called Semantic Lifting is used. In this layer, a given content is lifted to semantic level by extracting knowledge from it. To generate new knowledge based on existing knowledge and to represent this knowledge within an SMCS we need the third layer, called Knowledge Representation and Reasoning. The last layer persists the new knowledge in the Persistence layer. Starting with the initial four layer architecture we began our research on requirements. We also implemented semantic components in an iterative development process. The requirements were gathered by asking industrial CMS vendors for their needs and by doing research on possible semantic features [CES+ 09]. The requirements were consolidated and implemented in prototypical semantic components in an agile development process. The architecture was refined and adapted with each iteration of research and development [CEN+ 10]. In this paper, we present the resulting reference architecture for SCMS that addresses the 1 http://www.iks-project.eu (July 27, 2011) 136 domain-specific characteristics of such systems. This reference architecture has been implemented in two software development projects that are described as case studies. The reference architecture can be adapted in two different ways. On the one hand, the architecture can be used to enhance a traditional CMS with semantic features. On the other hand, the reference architecture provides support for the specification of SCMS from scratch. The remainder of this paper is structured as follows. At first, an overview about the stateof-the-art in engineering CMS is given in Section 2. In Section 3, traditional CMS architectures and their characteristics are discussed. Section 4 introduces the SCMS reference architecture that is applied in two case studies described in Section 5. Finally, the presented results are concluded and an outlook about future work is given in Section 6. 2 Related Work Recent research provides only few reference models for the development of SCMS. Based on the technologies and foundations developed for the Semantic Web, a stack architecture, termed the “Semantic Web Stack” as described in [Ber00], has been designed. This architecture has been extended in [HPPH05] with a rule layer. Both approaches provide a conceptual architecture by defining layers and assigning appropriate semantic technologies to these layers. Though, both approaches do not provide architectures that can be operationalized in the sense of development of software. They neither specify functionalities provided by layers or components nor the interaction between the layers. In [BKvH02] Sesame is introduced, a generic architecture model that focuses on storing and querying metadata in RDF and RDF schema. The architecture includes functional components that can be deployed. As described, this approach is restricted on a specific technology and thus limited to RDF and RDF schema. It mainly addresses persistence and data access components, whereas other functionalities like knowledge extraction or user interaction are not considered sufficiently. A server architecture for XML document management is proposed in [AMFK+ 00]. The architecture consists of a set of high-level layers that focus on the processing of textual documents. The approach is limited to XML-based content and does not provide solutions for the storing or extraction of knowledge from existing content. The “Context Broker Architecture” (CoBrA) described in [CFJ03] uses semantic web technologies in an architecture for context-aware information systems. The storage and access of knowledge and context reasoning is explicitly considered. The architecture is designed on a high level of abstraction and does not describe the different components and their interfaces in detail. In addition, dynamic processing of knowledge extraction is not in the focus of the approach. Summarizing the state-of-the-art in architecturing of SCMS, existing approaches do not provide a generic model that is independent from concrete technologies and considers all aspects of knowledge extraction and management. Another shortcoming of existing architectures is the lack of user interaction with knowledge providing an actual value of semantic technologies for the end user. 137 User Interface Content Access Content Administration Content Management Content Data Model Content Repository Figure 2: CMS Server Architecture 3 Traditional CMS Architecture CMS architectures are built upon the concept of a 3-tier architecture with client, CMS server, and database backend. Figure 2 shows the internal server architecture of a CMS. The main difference of CMSs compared to other information systems is to focus on flexible content modeling and storage. Content data models as the representation of content and their persistence need to be highly adaptable to any domain or customer scenario. A CMS User Interface at the top layer in Figure 2 presents the content and offers editorial features to create, modify, and manage content within its lifecycle. Access to the content itself is provided by a Content Access layer. This layer is used by the User Interface to get access to the content and the content management features of the CMS. Additionally, the Content Access layer can be used by third party software that may want to integrate the CMS into other applications. The core management features are implemented in the Content Management layer. This layer provides functionalities for the definition of the domain or application specific Content Data Model. Access control and content lifecycle definitions are further typical management features implemented in this layer. The Content Data Model layer is conceptually placed below the Content Management layer that has the necessary features to manipulate the model. The Content Data Model is the application specific model based on the underlying Content Repository. The Content Repository defines the fundamental concepts and persistence mechanisms for any Content Data Model that is defined on top. The Content Management features are tightly related to the Content Administration layer to administer the CMS stack. 4 Reference Architecture In an SCMS the content is stored in a traditional Content Repository and the knowledge about that content is additionally stored in a Knowledge Repository. Our proposal of an 138 SCMS Semantic Content Management System Semantic User Interface Content Knowledge User Interface Semantic User Interaction Content Access Knowledge Access Presentation & Interaction Knowledge Extraction Pipelines Reasoning Content Data Model Knowledge Models Content Repository Knowledge Repository Knowledge Administration Content Administration Content Management Semantic Lifting Knowledge Representation and Reasoning Persistence Figure 3: SCMS Reference Architecture SCMS reference architecture, as shown in Figure 3, is designed in such a way that any existing CMS, that has an architecture similar to the one depicted in Figure 2, can be extended to become an SCMS. This ensures that a CMS can be semantified without any major changes to the existing CMS. To create an SCMS out of a CMS the traditional CMS content column is extended by a second knowledge column for the semantic features in parallel. To interact with each other both columns are connected at the level of Content Access and Knowledge Access. The content of an SCMS is stored in the content column. Traditional content repositories are best prepared for this task. The content is transported from the content column to the knowledge column at the Content/Knowledge Access layer. For a loosely coupled solution, this could be done via some service implementation, e.g. RESTful Web Services [Fie00]. The delivered content can be analyzed by the components of the knowledge column. The obtained knowledge is stored in the knowledge column. Once the content column needs additional knowledge regarding some content it can query the content column. On the other hand the knowledge column can search for new or changed content in the content column. In summary, a SCMS is a CMS with the capability of interacting with, extracting, managing, and storing semantic metadata about content. In the following, we will describe the SCMS reference architecture along our coarse grained four layer concept shown in 139 Figure 1 that consists of Presentation & Interaction, Semantic Lifting, Knowledge Representation & Reasoning and Persistence. Presentation & Interaction In a traditional CMS, the user is able to edit and consume content through a user interface. When dealing with knowledge in SCMS we need an additional layer at the user interface level that allows a user to interact with content, called Semantic User Interaction. For example, a user writes an article and the SCMS recognizes the name of a person in that article. An SCMS includes a reference to an object representing that person – not only the person’s name. The user can interact with the person object and see, e.g. its birthday. The person is a knowledge object that is part of a Semantic User Interaction. Access to knowledge is encapsulated through a Knowledge Access layer similar to the Content Access layer. Whereas the content column of Figure 3 provides access to the content from the User Interface, provides the knowledge column access to knowledge for Semantic User Interaction. By combining existing features of a CMS User Interface layer with new feature from the Semantic User Interaction layer, an SCMS provides a Semantic User Interface layer on top of both. Semantic Lifting One problem for traditional CMS is the missing ability to extract knowledge in terms of semantic metadata from the stored content. Therefore, an SCMS defines a layer for Knowledge Extraction Pipelines that encapsulate algorithms for semantic metadata extraction. Typically, knowledge extraction is a multistage process [FL04] by applying algorithms known from the research field of Information Extraction and Retrieval. A Knowledge Extraction Pipeline defines that each stage of the pipeline produces results that are an additional input for the next stage [ELB07]. For example, a typical step in a Knowledge Extraction Pipeline is to identify all entities in a given content. Knowledge Representation & Reasoning After lifting content to a semantic level this extracted information may be used as inputs for reasoning techniques in the Reasoning layer. Logical reasoning is a well-known artificial intelligence technique that uses semantic relations to retrieve knowledge about the content that was not explicitly known before. To handle knowledge within the system we use Knowledge (representation) Models that define the semantic metadata used to express knowledge. These metadata are often defined along some ontology that specifies so-called concepts and their semantic relations. For example, persons and organizations are concepts and a semantic relation between these concepts may define that persons can be employees of organizations. Using this definition, one can express that a concrete person is an employee of an organization and this knowledge may have been extracted from a given content through a Knowledge Extraction Pipeline. In the same way the content column provides an extra orthogonal layer for Content Administration there is a need for a corresponding construct to administer knowledge. Knowledge Administration leads from the management of Semantic User Interaction templates, over Knowledge Extraction Pipeline and Reasoning management to the administration of Knowledge Models and Repositories. 140 Persistence Knowledge is stored in a Knowledge Repository that defines the fundamental data structure for knowledge. State-of-the-art knowledge repositories implement a triple store where a triple is formed by a subject, a predicate, and an object. Influenced by the ideas of the semantic web a triple can be used to express any relation between a subject and an object. To make this a semantic relation one has to define the Knowledge Models on top of the Knowledge Repository, e.g. to specify the semantic meaning of a certain predicate. In the following section, two case studies are introduced that demonstrate the applicability of our reference architecture in concrete project contexts. 5 Case Studies The concepts introduced by the SCMS reference architecture are validated through two distinct implementation projects. The first project is the IKS reference implementation (IKS-RI) project with the goal to deliver an implementation of the Knowledge column of the presented SCMS architecture in Section 4. The IKS-RI is validated through an industrial early adopters program where CMS vendors are invited to integrate the IKS-RI technology into their existing CMS and by this they create an SCMS. The major part of the IKS-RI is implemented as its own open source sub-project hosted at the Apache Software Foundation. This IKS subproject is called Apache Stanbol and was founded to create an independent open source community around the presented concepts of an SCMS. In this paper we reflect on the current work in progress status plus the planned features of the IKS-RI. The IKS-RI 1.0 release is scheduled for the end of 2011 and the Apache Stanbol community is supposed to push the development further on after 2011. The second project is a one-year student project that lasted from April 2010 to April 2011. The project was dedicated to develop an SCMS for the software engineering domain and is called Information-Driven Software Engineering – abbreviated as ID|SE. The idea is to create an SCMS that can handle large unstructured software specification documents and helps to extract the semantic information that is hidden in these documents. Therefore, the ID|SE platform tries to, e.g., identify pieces of content within a specification that describe a requirement. 5.1 IKS Reference Implementation The IKS-RI2 is used as a proof of concept implementation of the SCMS reference architecture. The implementation of IKS-RI and the development of the SCMS reference architecture is an intertwined process driven by open-source developers for the implementation and researchers for the reference architecture. Distinguished roles and viewpoints on the problem to support the development of SCMS ensured that all decisions made on 2 http://code.google.com/p/iks-project/ (July 27, 2011) 141 Reference Architecture IKS Reference Implementation Semantic User Interface IKS VIE Widgets jQuery User Interface Semantic User Interaction jQuery UI IKS VIE rdf Query Backbone.js Figure 4: Reference Architecture compared to VIE Architecture the implementation or the conceptual design were critically questioned. The IKS-RI implements the Knowledge column of the SCMS reference architecture (see Figure 3). Its implementation is divided into different open-source projects. The IKS-RI developers, amongst others the authors of this paper, use and support several existing opensource projects for their work. Examples are the Apache Clerezza3 project to manipulate semantically linked (RDF) data or the Apache OpenNLP4 project for natural language processing. Additionally, the developers are actively involved in the development of a newly founded open-source project, called Apache Stanbol5 , to implement the required knowledge features. Before describing the work done at Apache Stanbol we will first focus on the Semantic User Interaction layer of the reference architecture. Today, most CMS are web-based CMS whereas clients are primarily web browsers. Thus, the User Interface is implemented using modern Java Script browser technology. Along the traditional User Interface, the new Semantic User Interaction features are also required to work inside web browsers. The IKS/VIE6 sub-project makes use of a set of Java Script libraries, namely jQuery, Backbone.js, and rdfQuery and creates new semantic interaction widgets on top. The VIE architecture is depicted in Figure 4 in comparison to the reference architecture. VIE provides a framework at the Semantic User Interaction layer for user interaction widgets that can be used to create user interface components in the Semantic User Interface layer. Such widgets realize user interaction with content plus knowledge. A simple scenario is to edit a text and insert not just the literal name of the person but instead the entity person with the associated knowledge about that person. The Apache Stanbol architecture is built upon the OSGi [All11] component model implemented by the Apache Felix7 project. The OSGi model supports elegant separation of different components required by the Knowledge column. Each component is based on a Resource Oriented Architecture [Ove07] exposing their interfaces in terms of a REST [Fie00] API. The aggregation of the components’ interfaces forms an implementation of the Knowledge Access layer in Figure 3. This means that all components of Apache Stanbol address functionality within this layer and below of the reference architecture. Apache Stanbol 3 http://incubator.apache.org/clerezza/ (July 27, 2011) (July 27, 2011) 5 http://incubator.apache.org/stanbol/ (July 27, 2011) 6 http://github.com/IKS/VIE (July 27, 2011) 7 http://felix.apache.org/ (July 27, 2011) 4 http://incubator.apache.org/opennlp/ 142 Reference Architecture IKS Reference Implementation Knowledge Access Stanbol REST Service API Knowledge Extraction Pipelines Stanbol Enhancer Knowledge Repository Stanbol Reasoners Stanbol ContentHub Stanbol EntityHub Stanbol Ontology Mgr Apache Clerezza Apache Solr Apache Jena OSGi System Console Knowledge Models Knowledge Administration Reasoning Enhancement Engines Figure 5: Reference Architecture compared to IKS-RI Architecture does not address the top layers. The IKS-RI architecture for the SCMS layers starting with Knowledge Access is depicted in Figure 5. Apache Stanbol defines a sub-framework, called Stanbol Enhancer, to implement Knowledge Extraction Pipelines. Such a pipeline consists of Enhancement Engines in which each engine is responsible to automatically extract one piece of information. Subsequent engines can use information extracted by previously executed engines. At the end of this process a given content is enhanced with the extracted metadata that become knowledge. The most important knowledge that can be extracted with Apache Stanbol is the identification of certain types of entities within the content. Supported entities are e.g. persons and locations. The extracted knowledge is represented in a triple-graph structure provided by Apache Clerezza and stored with the use of the Stanbol ContentHub. The ContentHub provides access to previously enhanced content and allows to retrieve already stored knowledge for a given content. The EntityHub is used to retrieve semantic information about entities available through accessible Linked Open Data sources. A prominent example of a public Linked Open Data source is the DBPedia8 archive which provides access to the data available through Wikipedia9 . The EntityHub is able to search for entities in such data sources, to cache the information in an Apache Solr database, and to publish this information within Stanbol. Reasoning about knowledge is prepared through the Stanbol Reasoner component which is able to integrate existing reasoning engines. This reasoning implementation requires knowledge that is structured according to an ontology that can be managed by the Stanbol Ontology Manager. The Ontology Manager provides a management API for ontologies expressed in the Web Ontology Language (OWL) [W3C09]. Clients can query the Stanbol 8 http://dbpedia.org/ (July 27, 2011) (July 27, 2011) 9 http://www.wikipedia.org/ 143 Reasoner to gain new knowledge that is only implicitly present in the stored knowledge. The Stanbol Reasoner processes existing knowledge represented in an OWL ontology and is able to retrieve new knowledge, e.g. by using the semantic relations between entities defined through the ontology. Ontologies can be stored using Apache Jena which supports semantic web standards like the used OWL. The administration of all Apache Stanbol components is done via the OSGi System Console that is provided by the underlying Apache Felix OSGi implementation. Each component defines its own configuration parameters that can be manipulated via the System Console. For example, the used Linked Open Data source for the EntityHub is configurable through this mechanism. 5.2 Information-Driven Software Engineering The ID|SE project10 was a one-year student project with the goal to create an SCMS for the software engineering domain. Imagine a CMS in which one can upload unstructured requirements and specification documents and the system is able to identify specified requirements, actors, use cases, and components of the system plus the ability to reason about relations, e.g. between actors and use cases. Such an SCMS would help to structure the large amount of information written in plain text specifications. The ID|SE project used the publicly available specification of the German health card system for evaluation. The specification11 consits of more than 10,000 pages of text written in German including some tables plus a few informal figures and is available in Word or PDF format. In this paper, we focus on the ID|SE architecture and leave out the discussion about semantic features of the ID|SE platform. In Figure 6, we compare the reference architecture with the ID|SE version of an SCMS architecture. The ID|SE project realizes the Content column in Figure 3 on the basis of OpenCMS12 , an open-source CMS. In consequence, the ID|SE User Interface is implemented as an OpenCMS module. The focus of the ID|SE project was on features to analyze a given software specification document. The creation of sophisticated Semantic User Interaction components was not part of the project. That is the reason why the ID|SE architecture does not reflect Semantic User Interaction but only provides a User Interface without extra semantic capabilities. The ID|SE Service Platform API provides access through web services to the platform services that are realized by the IE/IR Service Orchestrators. To connect the Knowledge column with the Content column provided by OpenCMS the ID|SE project implemented an adapter in OpenCMS that informs the ID|SE platform about newly uploaded content to trigger the semantic lifting machinery and to transfer the content from OpenCMS to the ID|SE platform. The core of the ID|SE platform is a set of semantic lifting components that implement features from the research field of Information Extraction (IE) and Information Retrieval 10 http://is.uni-paderborn.de/fachgebiete/fg-engels/lehre/ss10/pg-idse/pg-idse.html 11 http://www.gematik.de/ (July 27, 2011) 12 http://www.opencms.org/ (July 27, 2011) 144 (July 27, 2011) Reference Architecture ID|SE Implementation User Interface ID|SE Presentation-Platform based on OpenCMS UI Knowledge Access ID|SE Service Platform API Knowledge Extraction Pipelines Knowledge Models Knowledge Administration Reasoning IE/IR Service Orchestrators IE/IR Services Information Aggregators Metadata Model Knowledge Repository Metadata Storage Figure 6: Reference Architecture compared to ID|SE Architecture (IR), respectively. This IE/IR services are executed in a pipeline by the IE/IR Service Orchestrators. In the following, we present a list of the IE/IR services used by the platform to give an impression of how this Knowledge Extraction Pipeline depicted in Figure 7 works. • Content Extraction Features to convert a given content in DOC or PDF format into a format that is suitable for being further processed by the pipeline. • Preprocessors Features to pre-process the content by applying techniques like tokenization of text, sentence detection, part-of-speech tagging, and word stemming. • Classifier A set of algorithms to classify pre-processed content according some classification schema. It is used for example to classify content as a text containing requirements or as a use case description. • Clusterer Features to partition large sets of documents into clusters of similar documents. This is used, e.g., to identify similar requirements as they are partitioned into the same cluster with these techniques. • Named Entity Recognizer Features to recognize named entities like actors, components, and use cases within the content. 145 Content Extraction PreClassifier processors Clusterer Named Entity Recognizer Figure 7: ID|SE IE/IR Services Pipeline After processing the documents by the IE/IR Services, the ID|SE platform provides additional features that are aligned to the reasoning capabilities of the reference architecture, called Information Aggregators. The Information Aggregators layer consists of components that collect semantic metadata that were extracted by the IE/IR Services and generates new metadata on that basis. The ID|SE platform provides three aggregators. • Entity Cover Calculator The Entity Cover Calculator computes the ratio between the coverage of named entities between two documents. This feature can be used, e.g., to search for documents that may be duplicates of each other like duplicate requirements. • Faceted Data Creator The Faceted Data Creator generates metadata for a faceted search user interface component. A faceted search lets users browse through large sets of documents by selecting different document categories. Each selection of a new category reduces the number of matching documents and allows an easy way to find a searched document. • Use-Case Model Recognizer Searches for use cases and actors in documents and creates UML [OMG10] use-case diagrams based on this information. The knowledge extracted by the IE/IR Services and the Information Aggregators is represented using the ID|SE specific Metadata Model. This model defines that each document consists of a number of artifacts in which each artifact is stored as a character sequence. This character sequence can be annotated with metadata defining that a certain sub-sequence contains a specific semantic information. Additionally, character sequences form tokens and sentences. The Metadata Model is implemented using the Java Persistence API (JPA) [Gro06] for storing these data into the Metadata Storage. The ID|SE platform uses the open-source relational database MySQL13 as its Metadata Storage which implements the Knowledge Repository layer of the reference architecture. 13 http://www.mysql.com/ (July 27, 2011) 146 6 Discussion & Future Work In this paper, we have motivated the need for a new generation of CMS that improve the handling of the growing amount of content by using semantic web technologies and IE/IR concepts. For these systems, termed Semantic Content Management Systems (SCMS) we proposed a reference architecture that supports the development of such systems by considering domain-specific requirements like the pipeline processing of knowledge extraction technologies. The reference model is intended to be used in different ways. The architecture can be adapted to develop an SCMS from scratch or to enhance existing, traditional CMS with semantic functionalities. The applicability of our approach in these two different ways has been evaluated by the implementation of the reference architecture in two software development projects. Applying the reference model to concrete implementation projects, the architecture provided a starting point for integrating semantic web and IE/IR technologies. The proposed structure ensures the consideration of all relevant aspects of semantic content and knowledge management by appropriate concepts. Hereby, the presented approach attains benefits for the design and implementation of SCMS. Addressing the experiences from the performed case studies, we identified three directions for the further work on our reference architecture. As a first step, the reference architecture will be evaluated as part of an overall evaluation in the IKS project. The applicability is measured by the expertises from the project consortium including partners from seven research institutions and six industrial CMS providers. Secondly, we will use best practices and feedback given by architects and developers from our case studies to concretize the different layers and their functionality to fine-granular components. In addition, conceptual interfaces for the interaction between these components will be defined. Through this, the applicability of the reference architecture in the technical design will be improved. Finally, we still see the potential for further improvement in the presentation and interaction layer of our architecture. The investigation of useful concepts for semantic user interaction and corresponding user interfaces is still part of our current work. The impact of these concepts on an architecture level needs to be analyzed in order to identify alignments for the reference architecture. References [AL99] Maryam Alavi and Dorothy E. Leidner. Knowledge management systems: issues, challenges, and benefits. Commun. AIS, 1999. [All11] OSGi Alliance. OSGi Service Platform - Core Service Specification Version 4.3, 2011. http://www.osgi.org/Release4/HomePage (July 27, 2011). [AMFK+ 00] Tim Arnold-Moore, Michael Fuller, Alan Kent, Ron Sacks-Davis, and Neil Sharman. Architecture of a Content Management Server for XML Document Applications. In 147 1st International Conference on Web Information Systems Engineering (WISE 2000), 2000. [Ber00] Tim Berners-Lee. Semantic Web XML2000, 2000. http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html (July 27, 2011). [BKvH02] Jeen Broekstra, Arjohn Kampman, and Frank van Harmelen. Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema. In Proceedings of the first Int’l Semantic Web Conference (ISWC 2002), Lecture Notes in Computer Science, pages 54–68. Springer, 2002. [CEN+ 10] Fabian Christ, Gregor Engels, Benjamin Nagel, Stefan Sauer, Sebastian Germesin, Enrico Daga, and Ozgur Kilic. IKS Alpha Development. Deliverable, 2010. http://www.iks-project.eu/resources/iks-alpha-development (July 27, 2011). [CES+ 09] Fabian Christ, Gregor Engels, Stefan Sauer, Gokce B. Laleci, Erdem Alpay, Tuncay Namli, Ali Anil Sinaci, and Fulya Tuncer. Requirements Specification for the Horizontal Industrial Case. Deliverable, 2009. http://www.iksproject.eu/resources/requirements-capture-through-use-cases (July 27, 2011). [CFJ03] Harry Chen, Tim Finin, and Anupam Joshi. Semantic Web in a Pervasive ContextAware Architecture. IN ARTIFICIAL INTELLIGENCE IN MOBILE SYSTEM 2003 (AIMS 2003), IN CONJUCTION WITH UBICOMP, pages 33–40, 2003. [ELB07] Michael Thomas Egner, Markus Lorch, and Edd Biddle. UIMA GRID: Distributed Large-scale Text Analysis. In Seventh IEEE International Symposium on Cluster Computing and the Grid, CCGRID 2007., pages 317–326, 2007. [Fie00] Roy Thomas Fielding. Architectural Styles and the Design of Networkbased Software Architectures. PhD thesis, University of California, 2000. http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm (July 27, 2011). [FL04] David Angelo Ferrucci and Adam Lally. Building an example application with the unstructured information management architecture. IBM Systems Journal, pages 455– 475, 2004. [Gro06] EJB 3.0 Expert Group. JSR 220: Enterprise JavaBeans,Version 3.0 Java Persistence API, 2006. http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html (July 27, 2011). [HPPH05] Ian Horrocks, Bijan Parsia, Peter Patel-Schneider, and James Hendler. Semantic Web Architecture: Stack or Two Towers? In Principles and Practice of Semantic Web Reasoning, pages 37–41. Springer, 2005. [LHL01] Berners Lee, J Hendler, and O Lassila. The Semantic Web. Scientific American, 2001. [OMG10] OMG. Unified Modeling Language (OMG UML), Superstructure, V2.3, 2010. http://www.omg.org/spec/UML/2.3/Superstructure/PDF (July 27, 2011). [Ove07] Hagen Overdick. The Resource-Oriented Architecture. IEEE Congress on Services, pages 340–347, 2007. [Sar08] Sunita Sarawagi. Information Extraction. Foundations and Trends in Databases, pages 261–377, 2008. [W3C09] W3C. OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax, 2009. http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/ (July 27, 2011). 148 Enriched Service Descriptions Using Business Process Configurations Mohammed AbuJarour, Ahmed Awad Hasso-Plattner-Institut University of Potsdam, Germany {firstname.lastname}@hpi.uni-potsdam.de Abstract: Service descriptions play a crucial role in Service-oriented Computing (SOC), e.g., for service discovery, service selection, service composition, etc. However, it has been observed that service providers – the main source of service descriptions – typically release poor service descriptions, i.e., mostly technical-oriented descriptions. Several approaches have been proposed to tackle this problem by enriching poor service descriptions with additional information from other sources, e.g., communities or domain experts. In this work, we propose a novel approach to generate additional information about web services based on the configurations of their consuming business processes. For instance, we can extract annotations and context information for web services based on the configurations of their consuming business processes. In this paper, we introduce our proposed approach and its architecture based on the open-source online modeling platform Oryx and our public service registry Depot. 1 Introduction: Service Descriptions Service-oriented Architecture (SOA) incorporates the main three roles of service-provider, -consumer, and -registry. Typically, service providers register their offered web services in one or more service registries that act as brokers between service providers and consumers. Such registries are then used by service consumers to discover web services that satisfy their (business) needs. Selected web services are then used as part of business processes (BP) running inside organizations, such as making a health insurance contract, selling items online, booking flights and hotels for journeys, etc. Typically, service consumers maintain repositories of business process models (BPM) for their daily activities, e.g., add new client, offer special promotions, etc. Each business process is composed of a set of tasks. Some tasks are manual tasks that are performed by employees, whereas others are service tasks performed through web services. Building a new BPM incorporates three steps: 1) creating and labeling its tasks 2) determining the interaction between them, i.e., data and control flow 3) configuring the created model, i.e., selecting web services to perform service tasks. The created BPM is then stored in the consumer’s repository for similar future requests. Using the aforementioned scenario in practice involves several challenges, e.g., service discovery, service selection, BP configuration. Service discovery has been one of the main challenges in Service-oriented Computing (SOC). Several approaches have been proposed 149 to tackle this challenge, e.g., semantic web service discovery [KLKR07]. However, such approaches assume the existence of rich and correct service descriptions. In practice, this assumption is not realistic because it has been observed that service providers release poor service descriptions [SWGM05]. Additionally, the assumption that service consumers’ queries during service discovery can be expressed formally using a query language is not realistic due to the increasing complexity of business needs and web services [Sun05]. During service discovery, a list of candidate web services are returned to the service consumer as a result for her submitted query. Choosing a particular web service to invoke from this list of candidates is known as service selection [SS04]. Service selection has become a complex task due to several factors, such as lack of rich service descriptions, increasing number of web services, increasing complexity of web services and modern business needs, etc. However, it has been shown that additional information about web services, e.g., annotations, helps meet this challenge [BTR10]. Business process configuration is the service selection step for service tasks in BPMs. In this step, each service task is assigned a web service to execute it. In practice, process engineers configure tasks manually using static lists of services they know already. To perform this task dynamically, process engineers require sufficient information about web services to configure their business process models accordingly. Technical-oriented information only is not sufficient, because it does not fit their backgrounds and knowledge [SBE07]. The “Internet of Services” initiative introduced the concept of “Business Services” to emphasize this requirement, namely, service descriptions should be understandable by business people, as well [SAP09]. In this work, we introduce a novel approach to use business process configurations to learn additional information about web services used in these processes. We have already introduced an approach to discover relationships among web services based on such configurations [AA11]. In particular, we consider extracting annotations for web services based on business processes that use them. 1.1 Research Context: Lack of Rich Service Descriptions Services are typically parts of one or more distributed business processes. Identifying tasks in a BP that should be implemented as web services is a system design decision. In general, system designers follow a bottom-up or top-down approach. In the bottom-up approach, existing web services are composed to achieve more complex tasks. This composition is repeated at higher levels until the required BP is achieved. On the other hand, the topdown approach means decomposing the complex task of the BP in question into sub-tasks iteratively until simple tasks are reached. Each simple service task is then implemented as a web service. The best practice is to follow a mix of both approaches to avoid high costs of the top-down approach and inflexibility of the bottom-up approach [Jos07]. In our approach, we follow this best practice, where we allow BP designers to get an overview of existing, relevant web services, and give them the chance to add more tasks that reflect their requirements. The fact that web services are typically parts of one or more distributed business processes 150 brings the challenges of service discovery and selection to business processes. Business processes and web services are usually separated and each of them is investigated individually. In this work, we introduce a novel approach to use business process configurations to derive additional annotations for the used web services from the service consumers’ perspective (business view) to enrich their technical service descriptions released by their providers. Several limitations can be identified in the current, traditional settings used in modern distributed information systems. In this work, we target the following limitations: • Lack of rich service descriptions: This limitation has been identified in both industry and research [BTR10, KTSW08]. Semantic web services tackle this problem by means of ontologies, but such approaches are not so common in practice [Bos08]. • Insufficient criteria for service selection: Service consumers take several factors into account when they select web service(s) they want to use, e.g., service quality, provider’s reputation, context in which the service is typically used, etc. Such information is usually provided by third parties, namely, service brokers (registries). However, context information is typically ignored. • Complex configuration of business processes: Creating business process models is labor-intensive due to the increasing complexity of modern business needs. Additionally, the configuration of business process models is error-prone due to the increasing complexity of web services and because it is usually a manual task . 1.2 Contributions The contributions of this work are: 1. A collaborative, incremental, and practical approach to enrich web service descriptions with annotations generated from the configurations of business processes that consume these web services. 2. Smooth configuration of business process models by enabling context-aware service selection. 3. Enhanced service discovery using both technical and business perspectives of service descriptions that are gathered from service providers and business process configurations, respectively. The rest of this paper is organized as follows: In Sec. 2, we discuss potential application domains for our approach. An overview of our approach is presented in Sec. 3. Further implementation details and application scenarios are given in Sec. 4. Related work is summarized in Sec. 5. We close this paper with a summary and future work in Sec. 6. 151 2 Application Domains Sharing information about business processes and web services used to achieve them is not usually desired by service consumers. This information might be considered one aspect of their competitive advantage. Nevertheless, our approach can be valuable in several scenarios and application domains, in particular, where there is a high potential for collaboration and a low potential for competition among service consumers, such as: 1. Government services: The number of governmental web services has been increasing steadily. For instance, the municipalities of the Netherlands have decided to use a common infrastructure to run their business processes [GWJV+ 09]. Several similar cases have also evolved in other European countries, such as Germany and UK. We give a detailed use case from this domain in Sec. 4.3. 2. Education: Web services are usually used in education to share information and offer computationally-intensive tasks. For instance in Life Sciences, web services are used to provide information about Genes, and extract protein encodings from natural text 1 . As collaboration between educational institutions is expected instead of competition, our approach can be applied in this application domain. 3. Online modeling platforms: Due to the increasing popularity of the Software -as-a-Service trend, several online modeling platforms are available on the Internet, e.g., Oryx 2 . Such platforms enable model sharing and collaborative modeling among communities, e.g., distributed teams. In such cases, our approach can be applied inside each community. 4. Quality-based service brokers: Several service brokers (registries) provide qualitybased service discovery and recommendation, e.g., www.asperado.com. Such brokers gather statistics about web services and measure their quality. These measures are then used to answer consumers’ requests to find relevant web services with specific quality constraints. In this scenario, our approach can be applied directly because the involved service consumers agree already to provide information about web services they use to service brokers. Due to policy and privacy issues, our approach cannot be applied to some application domains, such as banking. However, partial information about the used web services can be provided by service consumers, without leaking information about the internal structure of their business processes. 1 Several examples available on: http://www.biocatalogue.org 2 http://oryx-project.org 152 3 Annotations from Business Process Configurations Several approaches have been proposed to enrich poor service descriptions with additional information, such as websites of service providers [ANC10], invocation analysis [AN10], ontologies [SWGM05], etc. In [ANC10] we have introduced an automatic approach to annotate public web services with additional information that are extracted by means of crawling from the websites of their providers. However, this recent approach is limited to the content provided by service providers on their websites. Therefore, we introduced another approach to generate dynamic tags for data web services based on the analysis of their invocations [AN10]. This recent approach is not applicable to functional and business web services. Hence, additional sources and types of information about web services are still required. In this work, we introduce our approach to use BP configurations to gather additional information about web services. These three sources of additional information about web services are integrated together, indexed, and used to enhance service discovery. This architecture is depicted in Figure 1. Depot Service Discovery Service Recommendation <?xml v <ref: <r <?xml v <gr gr <ref: <gr XML WS WS WS A at nno ion t s Crawling A at nno ion t s Web A at nno ion t s Index BP Repository A + + B HTML C Invocation Analysis BP Configurations + + D Figure 1: Multiple sources of information about web services to enhance service discovery 3.1 Approach Overview The main goal of our approach is to enrich web service descriptions with annotations generated from the configuration of business processes that consume these services. To achieve this goal, we link business processes and web services. We give an overview of our approach to achieve this linkage in Figure 2. The scenario starts when a business process designer creates a new BPM. At that point, the designer gives a descriptive name and summary for the new process (Step 1), e.g., establish a company in Germany. Behind the scene, a request is sent to a service registry to find relevant web services that have been used in similar models (Step 2), e.g., establish a company in UK. The returned set of services is made available to the designer to select from. A by-product of this step is to accelerate the process designing step (Cf. Sec. 1.1). However, the process designer might not use all web services suggested by the service registry in the new model. She introduces new tasks to express their particular business 153 Service Consumers 1 3 New Business Process Model Model Name WS WS 5 Build Business Process Model Task Label Anno tation 2 WS WS Configure Business Process Model BPM+ Annotations Anno tation 4 Find Relevant Web Services Find Web Services for Tasks Task-WS Assignment Service Providers Business Process Repository Web Service Registry Task1 WS WS S WS S WS WS WS W WS WS W W WS WS Task2 Task3 Provided By WS WS WS WS Task4 Figure 2: A high-level overview of our approach to link BPs and web services needs (Step 3), where each task is given a label to identify it. This label is passed to the service registry to find potential web services that can perform the required functionality (Step 4). For each new task in the model, a list of candidate web services is returned to the process designer. Each web service is associated with a set of annotations that explain its functionality. These annotations are extracted and generated automatically from the websites of corresponding service providers [ANC10]. The new BPM is finalized when each service task is configured by assigning a web service to execute it (Step 5). With the finalized BPM, two types of information can be generated, namely, task-web service assignment and annotated BPM. The task-web service assignment is passed from the modeling framework to the service registry. Task labels and documentations are then extracted and their assigned web services are annotated with this extracted information. These labels and documentations are created by service consumers that represent the application level, i.e., business people. Whereas, the initial annotations are extracted and generated from the content released by service providers, i.e., technical people. Additionally, this assignment and the title of the created BPM are used to determine the context(s) where these web services are typically used. This information is then used to enable context-aware service selection for similar cases in future BPMs. The tasks in the created BPM are automatically annotated with the annotations of the web services they are bound with. The result is an annotated BPM. These annotations are crucial for BPM lookup because not only task labels are used to index and find tasks, but enriched annotations are also used to achieve this goal [Awa07]. This approach to enrich web service descriptions is collaborative and incremental. With each newly-created and configured business process model, the service registry gains addi- 154 tional annotations (e.g., labels) and information (e.g., context) about the used web services. These annotations and information are used to provide enhanced service discovery and enable smooth business process configurations due to context-aware service selection in later business process models. These advantages speed up the process design. Our approach is beneficial for both service registries and service consumers. Moreover, we believe that this is a practical approach to build rich semantic descriptions of web services, which can be considered as an additional step towards semi-automatic ontology construction. With such enriched service descriptions, more sophisticated approaches for service composition can be applied [AAMZM04]. It is worth mentioning that our approach does not suffer from a cold start. Available web services are already enriched with annotations that are collected automatically from the websites of their providers. The goal of our approach is to use these annotations to smooth BP configurations and generate additional annotations for them from the configurations of BPs that use them to reflect the service consumers’ (business) perspective, as well. 3.2 Formal Model A service registry usually contains a collection of web services. Each web service, W Si , has one or more operations. An operation, OPj , is given a name by its developer, e.g., GetWeather, and a list of annotations, A (by service registry). An annotation of an operation, a, can be a short sentence or several paragraphs describing that operation. These definitions can be expressed formally as follows: • Web service: W Si = {OP1 , · · · , OPn }; n ≥ 1 • Operation: OPj =< name, A >; A : annotations • Annotations: A = {a1 , · · · , am }; m ≥ 1, a : annotation A business process, BPk , has a list of tasks. Each task, Tl , has a label, documentation, and an optional operation, op, that executes that task if it is a service task. Formally, these definitions can be expressed as follows: • Business Proces: BPk = {T1 , · · · , Ts }; s ≥ 1, T : task • Task: Tl =< label, doc, op >; doc : documentation, op : operation Configuring a BP can be expressed as a function that takes a BP and assigns an operation to each service task in that BP. This function is defined formally in Equaion 13 . Conf : BP ! → {OP1 , · · · , OPy }; ∀Tb ∈ BP : OPc if Tb service task; OPc ∈ {OP1 , · · · , OPy } Tb .op = none otherwise (1) The newly-introduced effect of this configuration function is expressed formally in Equation 2. The label and documentation of each configures service task are appended to 3 We use the dot notation T.op to refer to the operation property of task 155 the annotation set of its assigned operation. These added annotations usually reflect the consumer’s (business) perspective of these operation. This perspective complements the providers’ (technical) perspective. Tx .op.A = Tx .op.A ∪ Tx .label ∪ Tx .doc (2) 4 Implementation and Application Scenarios We have implemented a prototype that realizes our approach to enrich service descriptions using business process configurations. In this section, we give details about the implementation of this prototype that integrates Oryx – an open-source business process modeling platform and repository – and Depot – a public web service registry. Our prototype is available at: https://www.hpi.uni-potsdam.de/naumann/sites/bpws/. The front-end of our prototype is Oryx, whereas Depot represents the backend. An end user, such as business process designer, interacts with an Oryx front-end to model her business processes. Behind the scene, Oryx contacts Depot to find relevant web services for each particular business process and its individual tasks. 4.1 Oryx: A Modeling Platform Oryx is an open-source, web-based graphical modeling tool and repository for business process models [DOW08]. Using a standard web browser, users can login to Oryx and create, modify and share business process models. Oryx supports a plethora of modeling languages, e.g, BPMN, Petri nets, UML, etc. Business process modeling languages are defined within Oryx by means of stencil sets. A stencil set describes the visual appearance of a model element, either node or edge, the set of properties it has and connectivity rules to other model elements. The user can define a stencil set extension to adapt a specific stencil set to a certain modeling domain. We use this feature to populate a process model with the set of web services returned from the service registry. In Oryx, a task has several properties, such as label, documentation, type, implementation, status, etc. During the configuration task, the implementation of each service task should be specified. 4.2 Depot: A Public Service Registry Depot is a service registry with multiple sources of information about web services, e.g., service providers, invocation analysis, service consumers[ANC10]. The information that Depot gathers is integrated into unified service descriptions that are used to provide enhanced service discovery. Depot uses an automatic approach to collect public web services 156 Figure 3: Example process model of establishing a UK limited company from the websites of their providers and annotate them [ANC10]. Traditionally, service consumers provide ratings, feedback, and other quality measures about web services. Although such information is valuable, it requires additional effort and is provided by service consumers explicitly. The assumption that the majority of service consumers give this information is not realistic. In our approach, two types of information are provided by service providers implicitly, namely, task labels and documentations as annotations for their assigned operations, and titles of BPMs as context for web services. 4.3 Use Case: Establishing a Limited Company in UK The European Union (EU) has been one of the main service markets. In 2006, the European Parliament and Council introduced the “Directive 2006/123/EC on services in the internal market” [Eur06], that aims to create a genuine internal market for services. Therefore, the directive seeks to remove legal and administrative barriers in order to make it easier for businesses to set up in other member states of the EU and to provide services cross-borders or on a temporary basis. The services offered by the UK Companies House 4 and other private service providers to establish a limited company in UK is an effort to apply this directive in UK. Figure 3 shows a process model using BPMN for establishing a UK limited company. The first six activities of the process are services of the UK Companies House. In the beginning, it has to be checked whether the desired company name is not already in use and the directors are not disqualified from leading a company. For the remaining steps, electronic forms are provided in the Portable Document Format (PDF). Last two activities in the model are web services offered by private service providers, e.g., Buy domain name can be executed using the whois web service (http://www.webservicex.net/ whois.asmx). Using our approach, a process engineer can configure her BPM to establish a company in UK using the existing annotations for web services and their operations used in such a model. These annotations are generated from the websites of their providers and through invocation analysis. Although, they might be not rich enough, such annotation can be helpful in some cases. Generating additional annotations for such web services and operations 4 http://companieshouse.gov.uk 157 from this BPM enrich their descriptions. In this particular use case, all used operations are associated with the context “establish a company in UK”. Additionally, each operation is annotated with the label and documentation of each task that uses it. For instance, the whois web service is annotated with “buy domain name”. 4.4 Our Approach in Action: Establishing a Company in Germany According to the German Federal Ministry of Economics and Technology, establishing a company in Germany incorporates 9 major steps 5 . For instance, check the company name, notarize the articles of association and foundation agreement, notify the Office of Business and Standards, register at the Trade Office (involves check manager’s qualifications), etc. Some of these steps are similar to the ones involved in establishing a limited company in UK (Cf. Sec. 4.3), such as check the company name, check qualified managers, rent office, buy domain name. Figure 4 shows a screenshot of using our prototype to design a business process for establishing a company in Germany. B A C Figure 4: A screenshot of our prototype used to model the process of establishing a company in Germany. A: suggested web services, B: a pre-configured task from A, C: task properties To create a new model for this process in Oryx, a proper title, such as “Establishing a company in Germany” is given by process designer. The area labeled with A in Figure 4 shows a list of web services discovered in Depot that have been used is similar contexts and are relevant to this process. For instance, the whois web services used in the UK example can be shown in this example despite the fact that there is no high similarity between terms appearing in “establish a company in Germany” and “whois”. Each of these web services is already configured and can be simply dragged-and-dropped to the design area. Indeed, 5 http://www.existenzgruender.de/englisch/ 158 the task labeled with B is an example of such pre-configured tasks. Saving this model adds additional information to Depot about the considered web services, such as the new labels and the current context. This additional information helps Depot provide better results in future similar cases, such as “Establishing a company in France”. 5 Related Work The problem of web service discovery is similar to looking for a needle in a haystack [GPST04]. Seeking the right service based on user’s search criteria in which the user may be interested is still one of the main challenges in SOC [HLV07]. Several factors exacerbate this challenge [Bos08]: • The increasing number of available web services on the web: With the increasing popularity of Software-as-a-Service and Cloud Computing, the number of public web services has been increasing steadily. For instance, Seekda (http: //webservices.seekda.com) reported more than 28,000 web services; • Keyword-based search: This factor is two-folded; from one side service providers typically release poor service descriptions that are not suitable for keywords matching. Additionally, today’s complex business needs make it difficult for consumers to even choose proper keywords; • Syntax-based search that ignores semantics of the terms used by service consumers (query) and service providers (service description). The lack of rich service descriptions is highlighted by several researchers in the community [KTSW08]. Therefore, researchers have proposed several approaches to gather additional information about web services to handle the problem of poor service descriptions [BCPS05, DJZB05, HK03, MB05]. In [ANC10] we introduced an approach to extract and generate annotations for public web services from the content that their providers publish on their websites. We showed also that additional annotations can be generated for web services based on the analysis of the their invocations, such as tags [AN10]. Tremendous work has been proposed to meet the challenge of service discovery. This work can be grouped into four categories: 1. Semantic approaches: These approaches treat the problem of service discovery as a matchmaking problem [LPC06]. Service consumer’s needs (goals) are captured in rich semantic expressions. These semantic expressions are then matched against the semantic descriptions of the considered web services. 2. Information Retrieval approaches: These approach investigate the semantic relationships between the term used by service consumers in their queries and those between the terms used to advertise the considered web services [MCZ07]. 3. Data mining approaches: These approaches transform the service discovery task into a constraint satisfaction problem, where the submitted query is matched against 159 the collection of web services. Graph traversal and clustering methods are typically used to solve the constraint satisfaction problem, where the relationships between the considered web services are used to increase the accuracy of the returned result list [YSZX07]. 4. Linking approaches: These approaches follow an integration approach to perform web service discovery. Typically, a set of web services that collectively satisfy a service consumer’s need is presented to the consumer. Service composition is then used to consume these web services [RS04]. In this work, we target two of the main limitations in existing service discovery approaches, such as the ones mentioned above: (i) The unrealistic assumptions of the availability of complete and correct service descriptions [FKL+ 05], and (ii) the ability of service consumers to express their sophisticated real business needs so that service discovery can be achieved [Sun05]. In the Adaptive Service Grid (ASG) project 6 , the authors assume that today’s complex business needs can be expressed (reasonably) by service consumers using ontologies to achieve a semantic service discovery. Our approach uses actual service usages in BPs to extract additional annotations to enrich their poor service descriptions that are used to provide enhanced service discovery, context-aware service selection, and smooth configuration of business process models. 6 Summary and Future Work We tackle the problem of lack of rich service descriptions and its effects on the configuration of BPs. Several approaches have been proposed to enrich poor service descriptions with additional sources of information, such as community annotations, domain experts, etc. In this paper, we introduced a novel approach to enrich poor service descriptions with annotations extracted from the configurations of BPs that consume them. Two types of information can be extracted from such configurations, namely, annotations from task-web service assignment and context(s) of web services. the extracted annotations help enhance service discovery in future cases. Context information enables context-ware service selection, and smooth BP configuration. We used Oryx and Depot to implement a prototype that realizes our approach. Oryx represents the front-end and Depot represents the back-end of our prototype. We showed how our approach can help create BPMs in several domains and introduced a detailed example to to model a process for establishing a company in Germany. Our approach is collaborative, incremental, and practical. The more we can ship back from process models to service registries, the better service discovery we can provide. In future, we will consider not only task-service assignments but also global behavioral relationships imposed on services by process models via their tasks. We believe that this is of crucial importance to achieve service composition in a practical way. 6 www.asg-platform.org 160 References [AA11] Mohammed AbuJarour and Ahmed Awad. Discovering Linkage Patterns among Web Services using Business Process Knowledge. In Proceeding of the International Conference on Services Computing, Washington, DC, USA, 2011. IEEE Computer Society. [AAMZM04] I. Budak Arpinar, Boanerges Aleman-Meza, Ruoyan Zhang, and Angela Maduko. Ontology-Driven Web Services Composition Platform. In Proceedings of the IEEE International Conference on E-Commerce Technology, pages 146–152, Washington, DC, USA, 2004. IEEE Computer Society. [AN10] Mohammed AbuJarour and Felix Naumann. Dynamic Tags For Dynamic Data Web Services. In Proceedings of WEWST’10, Ayia Napa, Cyprus, 2010. ACM. [ANC10] Mohammed AbuJarour, Felix Naumann, and Mircea Craculeac. Collecting, Annotating, and Classifying Public Web Services . In OTM 2010 Conferences, Crete, Greece, 2010. Springer. [Awa07] Ahmed Awad. BPMN-Q: A Language to Query Business Processes. In Proceedings of EMISA’07, volume 119, pages 115–128, St. Goar, Germany, 2007. [BCPS05] Marcello Bruno, Gerardo Canfora, Massimiliano Di Penta, and Rita Scognamiglio. An Approach to Support Web Service Classification and Annotation. In Proceedings of EEE’05, pages 138–143, Washington, DC, USA, 2005. IEEE Computer Society. [Bos08] Aishwarya Bose. Effective Web Service Discovery using a Combination of a Semantic Model and a Data Mining Technique. Master’s thesis, Queensland University of Technology, Queensland, Australia, 2008. [BTR10] Stephan Buchwald, Julian Tiedeken, and Manfred Reichert. Anforderungen an ein Metamodell für SOA-Repositories. In Christian Gierds and Jan Sürmeli, editors, ZEUS, volume 563, pages 17–24. CEUR-WS.org, 2010. [DJZB05] Zhang Duo, Li Juan-Zi, and Xu Bin. Web Service Annotation Using Ontology Mapping. In Proceedings of SOSE ’05, pages 243–250, Washington, DC, USA, 2005. IEEE Computer Society. [DOW08] Gero Decker, Hagen Overdick, and Mathias Weske. Oryx - An Open Modeling Platform for the BPM Community. In BPM, volume 5240 of LNCS, pages 382–385. Springer, 2008. [Eur06] European Parliament and Council. Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006 on services in the internal market. ISSN 1725-2555, December 2006. [FKL+ 05] Dieter Fensel, Uwe Keller, Holger Lausen, Axel Polleres, and Ioans Toma. WWW or what is wrong with web service discovery? In Proceedings of the W3C Workshop on Frameworks for Semantics in Web Services, 2005. [GPST04] John Garofalakis, Yannis Panagis, Evangelos Sakkopoulos, and Athanasios Tsakalidis. Web Service Discovery Mechanisms: Looking for a Needle in a Haystack? In International Workshop on Web Engineering, 2004. [GWJV+ 09] Florian Gottschalk, Teun A. Wagemakers, Monique H. Jansen-Vullers, Wil M. Aalst, and Marcello Rosa. Configurable Process Models: Experiences from a Municipality Case Study. In Proceedings of CAiSE’09, pages 486–500, Berlin, Heidelberg, 2009. Springer-Verlag. 161 [HK03] Andreas Heß and Nicholas Kushmerick. Learning to Attach Semantic Metadata to Web Services. In International Semantic Web Conference, pages 258–273. Springer, 2003. [HLV07] Stephan Hagemann, Carolin Letz, and Gottfried Vossen. Web Service Discovery Reality Check 2.0. In Proceedings of NWESP ’07, pages 113–118, Washington, DC, USA, 2007. IEEE Computer Society. [Jos07] Nicolai M. Josuttis. SOA in Practice: The Art of Distributed System Design. O’Reilly, 2007. [KLKR07] Ulrich Küster, Holger Lausen, and Birgitta König-Ries. Evaluation of Semantic Service Discovery- A Survey and Directions for Future Research. In Postproceedings of WEWST’07, 2007. [KTSW08] Dominik Kuropka, Peter Tröger, Steffen Staab, and Matthias Weske. Semantic Service Provisioning. Springer, Germany, 2008. [LPC06] Chuanchang Liu, Yong Peng, and Junliang Chen. Web Services Description Ontology-Based Service Discovery Model. In Proceedings of WI ’06, pages 633– 636, Washington, DC, USA, 2006. IEEE Computer Society. [MB05] Brahim Medjahed and Athman Bouguettaya. A Dynamic Foundational Architecture for Semantic Web Services. Distrib. Parallel Databases, 17(2):179–206, 2005. [MCZ07] Jiangang Ma, Jinli Cao, and Yanchun Zhang. A Probabilistic Semantic Approach for Discovering Web Services. In Proceedings of WWW ’07, pages 1221–1222, New York, NY, USA, 2007. ACM. [RS04] Jinghai Rao and Xiaomeng Su. A Survey of Automated Web Service Composition Methods. In Proceedings of SWSWPC’04, pages 43–54, 2004. [SAP09] SAP Research. Unified Service Description Language. internet-of-services.com, 2009. [SBE07] Sebastian Stein, Katja Barchewitz, and Marwane El Kharbili. Enabling Business Experts to Discover Web Services for Business Process Automation. In Proceedings of WEWST, Halle (Saale), Germany, 2007. [SS04] Raghuram M. Sreenath and Munindar P. Singh. Agent-based Service Selection. J. Web Sem., 1(3):261–279, 2004. [Sun05] Sun Microsystems. Effective SOA Deployment using an SOA Registry Repository, A Practical Guide, 2005. White paper. [SWGM05] Marta Sabou, Chris Wroe, Carole Goble, and Gilad Mishne. Learning Domain Ontologies for Web Service Descriptions: An Experiment in Bioinformatics. In Proceedings of WWW’05, 2005. [YSZX07] Jianjun Yu, Hao Su, Gang Zhou, and Ke Xu. SNet: skip graph based semantic web services discovery. In Proceedings of SAC ’07, pages 1393–1397, New York, NY, USA, 2007. ACM. 162 http://www. Developing a Cloud Provider Selection Model Jonas Repschläger1, Stefan Wind2, Rüdiger Zarnekow1, Klaus Turowski2 1 Chair of Information and Communication Management Technical University Berlin, Sekr. H 93, Straße des 17. Juni 135, 10623 Berlin jonas.repschlaeger@ikm.tu-berlin.de, ruediger.zarnekow@ikm.tu-berlin.de 2 Chair of Business Information Systems I Otto-von-Guericke University Magdeburg, Universitätsplatz 2, 39106 Magdeburg stefan.wind@ovgu.de, klaus.turowski@ovgu.de Abstract. Recently, a growing development and use of Cloud computing services has been observed. Especially modeling cross-organizational cooperation and the respective provider comparison are gaining importance. Despite initial positive results, it is challenging in theory and practice to find an appropriate provider matching the individual requirements. Moreover, the comparison process is complicated by a number of new entrants as well as offers of non-transparent services, which sometimes differ significantly. Due to the lack of adequate possibilities to compare and classify Cloud providers we are presenting in this paper a provider independent classification model for Infrastructure as a Service (IaaS). For this purpose, the target dimensions for Cloud Computing from a customer perspective were defined, based on expert interviews, an international literature review and a Cloud provider market (IaaS and hosting) analysis. 1 Motivation For several years Cloud Computing has been influencing the IT landscape and has been an important economic factor. Gartner predicts a strong growth of Cloud services with a worldwide revenue of 146.8 billion US dollars in 2014 [Pr09]. In this context, Cloud Computing has become a fast growing and non-transparent market with many small and large providers, each of them having their specific service model [RZ11a], [HK10], [VJ10]. That makes it difficult to compare the providers as such and their service offerings. In the majority of cases the service portfolios are heterogeneous and combined with complex pricing models and service features. Furthermore, the fact that interoperability between providers hasn’t been achieved makes a provider selection often irreversible or requires much effort [HK10], [RZ11b]. This difficulty, known as “provider lock-in”, is discussed extensively and is an important topic in many companies and international research activity e.g. Open Grid Forum (OGF) [CH09], [Ar09]. Consequently, the customer is confronted with the situation to select an appropriate provider to realize his specific requirements 163 mostly based on diffuse classification criteria. Due to the lack of adequate possibilities of comparing a Cloud provider, especially on the infrastructure level, this paper focuses on developing a classification model for IaaS providers. In this context the following research question need to be answered: What are appropriate classification characteristics for Cloud providers and what should an Infrastructure as a Service (IaaS) classification model look like? To reduce entry barriers and support the migration into the Cloud this paper starts with examining Cloud Computing characteristics and the IaaS provider’s market. Based on a literature review and interviews conducted with experts we have derived six customer target dimensions valid for Cloud Computing (see chapter 4). These target dimensions serve as strategic objectives regarding Cloud Computing and provide a structure for Cloud characteristics in the first place. Next we gathered all requirements available and appropriate classification criteria for Cloud providers and reviewed them in cooperation with the experts. On this basis we have developed a classification model by assigning relevant provider and service requirements to the target dimensions using a four level hierarchy (see chapter 5). We defined 17 classification criteria on the 2nd level and 51 criteria on the 3rd level. 2 Cloud Computing introduction With Cloud Computing a paradigm shift to standardization and service orientation in the information and communication industry emerges and marks the industrialization of IT [Le10]. Cloud Computing allows companies to rent IT services on demand to support their business processes. As a new part of IT sourcing, the effort of operation and maintenance is completely managed by the provider. The customer only rents the service in a pay-per-use manner like a commodity similar to the energy or water market. Considering the extensive usage of on demand services, mobile applications and interactive elements, transactions and workloads will rise significantly and require scalable IT structures [La10]. This growing acceptance will result in an increasing demand for IT resources. At this point the Cloud Computing model is essential. It makes on demand network access to a shared pool of configurable computing resources possible, that can be rapidly provisioned and released with minimal management effort or service provider interaction [GM09]. The resources (e.g. networks, servers, storage, applications and services) are offered in a scalable way via the Internet without the need for any long-term capital expenditures and specific IT knowledge on the customer side. It is possible to obtain complete software applications or the underlying IT infrastructure in the form of virtual machine images. Basically Cloud Computing is composed of the characteristics above described and consists of three levels, software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS) [GM09]. 164 On the infrastructure level customers have the possibility to obtain on demand resources from a Cloud provider with no need to operate the required IT infrastructure. On the one hand, the customer can extend his existing IT infrastructure by renting additional capacity from the Cloud to compensate load peaks, preventing the customer from having much capacity available. On the other hand, the complete infrastructure and respective services can be obtained from the Cloud. This decreases the IT maintenance effort and creates value especially for small businesses with fluctuating demand, e.g. due to seasonal activities. Alongside the benefits of Cloud Computing, several challenges emerge on the management level regarding different technological components and modules, integration of heterogeneous interfaces, usage dependent provisioning and billing of resources as well as ensuring data privacy and data security [IH10], [Bi10], [Cl09]. 3 Research Methodology Cloud Computing is characterized by various factors and a common definition of this term doesn’t exist [We09], [Wa08], [Va09]. Thus Cloud Computing was examined from different perspectives (technological, business issues, applications and general aspects) [YT09]. According to this, we attempted to develop an IaaS classification model which would be valid for all research fields without limitation. Prior to the literature review five experts were interviewed on common objectives in Cloud Computing. As a result four target dimensions for the Cloud could be derived. The expert interviews were conducted with five experts from four companies, all holding different positions within their companies. Care was taken that those respondents were representative of all perspectives (provider, customer and mediator/consultant) being important for the selection process (see Table 1). The interviews with the experts were structured and conducted referring to Glaeser and Laudel [GL10]. Table 1. Type of experts interviewed (Expert from) Company type Position within company Company data 170.000 employees Global IT service offerings IT service provider Software provider Software provider Consulting company Customer / Client 10-15% revenue based on Cloud Computing Innovative solutions in IaaS SME software company 11 employees Development of standardized components for web-based services SME software company 11 employees Development of standardized components for web-based services International consulting company 500 consultants worldwide Cloud Computing as one consultancy topic Automotive sector ca. 95.000 employees Director of IaaS division CIO Software architect Partner Divisional director IT 165 Cloud experience Deep understanding of IaaS services and infrastructure Expert know-how in SaaS and general Cloud approaches Expert knowledge in IaaS and PaaS especially in the implementation Current consulting focus; Cloud market appreciation Experience in selecting, implementing and operating IaaS Next, in order to describe, synthesize, evaluate and integrate the results of existing scientific work in comparison of Cloud providers and distinguishing criteria of Cloud offerings, we conducted a systematic literature review following the approach of Webster and Watson [WW02]. This research method ensures that an extensive number of relevant papers considered. During the literature review we attempted to match each criterion gathered to a representative target dimension. The necessity emerged to define two more target dimensions in order to allocate all relevant criteria. Afterwards the additional dimensions were discussed and evaluated with the experts as well. The outcomes were six target dimensions, each including a group of relevant classification criteria. The first step in the literature selection process was conducted to identify a comprehensive list of literature sources. We started off by taking the top journals based on the VHB-JOURQUAL2 [SH09] and Saunders’s journal ranking [Sa11b]. To complete the analysis, publications of renowned national and international organizations and associations (e.g. Bitkom) were included. Table 2 lists all literature sources that were examined to identify relevant papers. Table 2. Journals and conferences investigated for the literature review Publication type Publisher Journals ACMSIG, CACM, CAIS, CompDcsn, DATABASE, DSI, DSS, EJIS, I&M, I&O, IBMSJ, IEEEComp, IEEESw, IEEEIC, IEEETC, IEEETKDE, IEEETrans, IEEETSE, IEEETSMC, IJEC, IJHCS, InfoS ys, ISF, ISJ, ISM, ISR, IT&M, IT&P, JACM, JAIS, JCIS, JComp, JCSS, JIM, JITTA, JMIS, JSIS, KBS, MISQ, MS, SMR, WIRT Conferences Associations, Organizations, Companies AMCIS, ECIS, ICIS, HICSS, IEEE Conferences, LNI, LNCS, MKWI, PACIS, WI Cloud Security Alliance (CS A), EuroCloud, Bi tkom, Bundesamt für Sicherheit in der Inform ationstechnik (BSI), Securing Europe's Information Society (ENISA), Center for Experimental Researchin Computer Systems (CE RCS), Fraunhofer SIT, Distributed Managem ent Task Force (DMTF), The European Telecommunications Standards Institute (ETSI), National Institute of Standards and Technology (NIST), Open Grid Forum (OGF), Object Managem ent Group (OMG), Open Cloud Consortium (OCC), Organization for the Advancement of Structured Information Standards (OASIS), Storage Networking Industry Association (SNIA), The Open Group, TM Forum, SaaS EcoSystem, OpenCloudMani festo, Experton Group, TSystems In a subsequent step, we chose topic related papers from the selected literature sources. An initial list of papers was generated by using key words such as “Cloud Provider”, “Cloud Vendor”, “Cloud Characteristics”, “Cloud Classification”, “Cloud Selection”, “Cloud Taxonomy”, “IaaS”, “Infrastructure as a Service”, “Platform as a Service”, “Software as a Service”, “PaaS” and “SaaS” to search for titles, abstracts and keywords. We only scanned the directories of the journals and conference proceedings manually if no electronic search was possible. Furthermore, we expanded our scientific foundation by reviewing the citations in the papers identified in the first cycle of literature exploration to determine previous papers that should be considered for an analysis in a subsequent cycle of literature exploration. 166 We identified 55 papers all dealing with the comparison of Cloud providers or at least containing related keywords. In order to identify the final set of publications we subjected these papers to a detailed (content-related) review. Therefore, we manually reviewed the papers of the initial list and selected only those papers which primarily dealt with the comparison of Cloud providers. Thus, 38 articles were selected which dealt primarily with the classification or selection of Cloud providers and distinguishing criteria of Cloud offerings. It is surprising that almost the entire set of finally selected papers consists of conference papers and there is just a small amount of high-quality journal papers available. This probably shows that there is a lack of research regarding the classification of Cloud services and distinguishing criteria of Cloud offerings. Complementary to the literature review the provider market of IaaS and hosting were investigated. This analysis was based on an extensive internet research where the websites of relevant companies were examined regarding their pricing model, IaaS service offering, company data and customer segment. By means of market studies and business publications on the Cloud market we detected over 60 relevant providers in the IaaS and hosting business [VJ10], [LC10], [HF09]. Based on this analysis we compiled a feature catalog for IaaS providers. In order to develop a detailed proposal for an IaaS classification model the target dimensions including the related criteria from the literature review were matched with the features of the provider catalog supported by the experts. Thereby, a designoriented approach was used. 4 Target Dimensions in Cloud Computing In this contribution we define six target dimensions - such as cost savings or increasing flexibility - to group and structure the Cloud characteristics. Each target dimension represents a general objective which the customer pursues and which characterizes his Cloud or IT strategy. Four target dimensions (costs, IT security & privacy, scope & performance, reliability & trustworthiness) were defined together with the experts prior to our analysis. Through our literature review and market research, we validated these four dimensions and simultaneously discovered two additional dimensions (flexibility and service & Cloud management), which were evaluated subsequently by the experts as well. Table 3 shows the relevant sources assigned to the six target dimensions. In this context we discovered that practitioners mainly deal with questions about security, reliability and manageability of Cloud Computing. Largely unnoticed, however, remain so far the performance as well as the cost / price models. Science is exploring the topic covering all target dimensions and attaches significantly more importance to the performance dimension. 167 Table 3. Results of the literature review IT Security & Compliance Service & Cloud Management Source Reliability & Trusttworthines Scope & Performance Costs Flexibility Target Dimension 30 29 14 27 18 Academic Publications Günther et al. (2001) Hilley (2009) Hoefer and Karagiannis (2010) Li et al. (2010) Prodan and Ostermann (2009) Annecy (2010) Vaquero et al. (2009) Peng et al. (2009) Weinhardt et al. (2009) Hay et al. (2011) Martens et al. (2010) (2011) Christmann et al. (2010) Tsvihun et al. (2010) Armbrust et al. (2010) Iyer und Henderson (2010) Anandasivam and Premm (2009) Lehmann et al. (2009) Rimal et al. (2009) Schwarz et al. (2009) Talukder et al. (2010) Koehler et al. (2010) (2010) Saya et al. (2010) Narasimhan et al. (2011) Russell et al. (2010) Popularity 36 41 35 Industry Publications BITKOM (2010) BSI (2010) EuroCloud (2010) ENISA (2009) CSA (2009) SaaS EcoSystem (2011) DMTF (2009) (2010) OpenCloudManifesto (2009) T-Systems (2008) Experton Group (2010) The Open Group (2009) Popularity Low priority 21 6 1 Average priority 168 24 High priority 4.1 Target Dimension: Flexibility An associated advantage of Cloud Computing, identified in science and industrial practice, is the gain in flexibility compared to traditional solutions [We09]. Resources, for example, can be allocated and de-allocated as required, whereas requirements can sometimes vary greatly. The provisioning time is shorter compared to traditional outsourcing such as Application System Provider (ASP) and with a very small overall commitment period to the vendor [RZ11a]. Also other aspects such as standardization (e.g. APIs), the traceability of data, the short-term contracts or a demand-driven and scalable resource recovery have to be considered regarding an appropriate supplier selection. 4.2 Target Dimension: Costs The decision to choose Cloud Computing and a particular provider is often guided by monetary considerations [Hi09] and linked with the slogan "pay-as-you-use". Customers who decide to use Cloud services benefit mostly from small capital commitment, low acquisition costs for required servers, licenses or necessary hardware space and the reduced complexity of IT operations. Despite similar services on the IaaS level the pricing and billing models often differentiate between each provider [RZ11a]. 4.3 Target Dimension: Scope & Performance With this target dimension the scope of services and the performance of a Cloud provider are described. To select the Cloud provider which best meets the requirements, knowledge about their service and performance is of crucial importance [Ar09]. Here it is essential to consider features regarding performance (latency, or transaction speed), capacity limits (e.g. maximum number of accounts or storage space), service complexity (how many functions are available) and degree of customization (how far the service can be adapted). 4.4 Target Dimension: IT Security & Privacy The decision on selecting a provider in the Cloud is very often influenced by company requirements in the areas of security, compliance and privacy [CH09], [Ts10], [Ja08], [Cl09]. Companies have to be sure that their data and applications, even operated in the Cloud, meet the required compliance guidelines of both and are adequately protected against unauthorized access. Here, the decision criteria are rather referring to the infrastructure of the provider itself than to the provided service. 169 4.5 Target Dimension: Reliability and Trustworthiness This target dimension describes how certain the customer can be that the service from the Cloud has the guaranteed availability [Ja08]. It is important to know what commitment the provider makes, mostly in form of Service Level Agreements (SLAs). Moreover, the reliability with which these commitments are kept is of great importance. In contrast to the commitment, the trustworthiness describes the provider's infrastructural features, which may be evidence of a high reliability. These include disaster recovery, redundant sites or certifications. 4.6 Target Dimension: Service & Cloud Management The Service & Cloud Management includes features of the provider that are substantial for convenient Cloud service operations. These include the offered support and functions for controlling and monitoring as well as the individualization of the web interface [YT09]. The manageability (usability) of services, especially in a distributed IT architecture, and the Cloud governance, dealing with requirements and responsibilities by the customer, are essential features of this target dimension. 5 Classification Model for Infrastructure as a Service (IaaS) The aim of this paper is to develop a classification model for supporting a Cloud service selection on the infrastructure level. The model may help companies in their selection process and creates greater transparency in the Cloud market. For that purpose, different target dimensions were elaborated (chapter 4). These dimensions cover the Cloud Computing in its entirety and aren’t limited to one level (SaaS, PaaS, IaaS). Next, these dimensions have to be broken down into selection criteria that are measureable and comparable. Based on the fact that all three Cloud levels are targeting different customer needs, it wasn’t possible to define selection criteria valid for all levels at once. At this point, we limited our examination to the infrastructure level (IaaS) because in our opinion the services are particularly convenient due to a certain degree of consistency. With the purpose of developing a classification model we summarized and mapped similar characteristics and requirements regarding their target dimension into three hierarchical levels (see Figure 1). Thereby abstract and operational selection criteria were identified. The abstract selection criteria are used for further structuring and differentiation purposes. On the third level of the classification scheme, criteria have been operationalized, so that they can be weighted and compared (e.g. pricing options, delivery time). The level below finally defines figures and measurable requirements (key performance indicator, KPI). Each operative criterion (3. level) consists of various level 4 requirements. Furthermore, requirements can be divided into provider requirements and service requirements (see Figure 1). Provider requirements describe the features of the Cloud provider independently from any service, e.g. existing certifications, IT infrastructure characteristics or key figures of the company. Service requirements in contrast deal 170 with characteristics directly referring to the usage of a service, e.g. service availability, scalability or interface features. Classification scheme example: The target dimension “Flexibility” (1st level) consists of “service dynamics” among other things, an abstract classification criterion (2 nd level) which is characterized through the provisioning time (3rd level). The “provisioning time” is measured among other things by the required time to start up an instance (4th level; KPI). For instance, if the deployment time is less than five minutes, the provisioning time is rated as low, assuming the other requirements will be rated similarly. 1st level general objectives of Cloud Computing target dimensions 2nd level specific classification of Infrastructure as a Service abstract classification criteria 3rd level operative classification criteria service requirements 4th level requirements / KPI provider requirements Fig. 1: Classification scheme The result of this paper is a classification model with six target dimensions, 17 abstract selection criteria (2. level) and 51 operative selection criteria (3. level). This model is illustrated in Figure 2. For reasons of clarity the requirements on level four are not shown. 171 Costs Flexibility interoperability & portability standardisation price model data portability network configuration Scope & Performance technology price class load balancing virtualization price resilience multi-tenancy network access price options automatisation degree software price transparency resource scalablity changes / updates system management payment options payment method service dynamics service charging provisioning time instance customizing contract length charging granularity scalability charging type set-up time IT Security & Privacy datacenter security hardware security performance computing time reliability incident und service management redundancy (network) trustworthiness support contact and consulting services service operations data protection provider reporting auditing system management datacenter location service transparency provider profile Controlling network security service level agreements availability usability connection opportunities liability and penalties customizing options abstract selection criteria reporting and monitoring web portal connection security target dimension instance capacity connection bandwidth Service & Cloud Management redundancy (datacenter) data protection & compliance add-on services Reliability and Trustworthiness disaster recovery software security instance type storage service operative selection criteria Fig 2: Classification model for IaaS (without KPIs) Next, the selection criteria and target dimensions will be briefly explained. The classical target dimension is the flexibility, which describes the ability to respond quickly to changing capacity requirements. Here, the topics interoperability & portability, automation and service dynamics are particularly noteworthy. But there are far more important aspects in supplier selection. These include, for example, price stability (duration of the agreed price) and the granularity of allocation (e.g. 1 MB, 100 MB or 1 GB steps). Between IaaS providers in particular, the pricing (price range, pricing options, price transparency, payment options etc.) and billing model differentiate clearly. The performance is regarded as a relevant criterion for selection by the experts, although it was marginally discussed so far in practice (see Table 3). The efficiency and the scope of services can be divided into performance, technology and software. Criteria like the max. CPU, RAM, hard drive, transfer volumes and transfer speed belong to the topic of performance. Features such as the type of virtualization, the load balancing and so on will be subsumed under the term 172 technology. This target dimension is completed by software characteristics, such as the selection of different operating systems. The target dimension of IT security is attracting particular attention in practice and refers to the data center or network. There are requirements for privacy (encryption of data) and compliance (e.g. location of data center) as well. Using external services from the Cloud, trustworthiness and reliability are very important. In this field they can be grouped into commitment (which efforts are guaranteed by the provider, service SLAs), reliability (the probability that service pledges can be met) and trustworthiness (e.g. performance transparency, market experience). The target dimension Cloud & Service Management can be differentiated according to incident and service management (support and customer service), service operation (e.g. monitoring of services and volume control via APIs) and web portal (usability and adaptability of the surface). 6 Conclusion & Future Work Based on our literature and provider review, complemented by interviews with specialists in the respective field, we introduced in this contribution a classification model enabling a provider selection on the IaaS level. Our view is that via the model, companies are able to support their decision process and simplify the provider comparison. In this way, heterogeneous IaaS offerings in the Cloud can be compared a lot easier and the time of the selection process can be accelerated as well. It is conceivable that via middleware or standardized interfaces different IaaS offerings can be automatically selected and offered based on the customer preferences (target dimensions). Cloud actors like mediators or aggregators are becoming more important. The consequence is a shift from a subjective provider assessment to a mostly fact -based performance selection where the realization of service requirements is gaining importance. There is no need for customers to know from which provider they obtain the service as long as the requirements are met. As further research approach, the classification model will be evaluated and refined. Therefore IT managers will be surveyed and various case studies will be conducted to ensure applicability of the presented classification model. 7 References [AP09] Anandasivam, A., and Premm, M., “Bid price control and dynamic pricing in Clouds,” in Proceedings of the European Conference on Information Systems, Verona, Italy, 2009. [An10] Annecy, M.: XaaS Check 2010 Status Quo und Trends im Cloud Computing. S.A.R.L. Martin, Forschungsgruppe Service-oriented Computing,Technische Universität Darmstadt und IT Research, Sauerlach. 2010. [Ar09] Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R.H., Konwinski, A., Lee, G., Patterson, D.A., Rabkin, A., Stoica, I. and Zaharia, M., “Above the Clouds: A 173 [Bi10] [Bs10] [CH09] [Ch10] [Cl09] [Di09] [Di10] [Eu10] [GL10] [GM09] [Gü01] [Hi09] [HK10] [Ha11] [HF09] [IH10] [Ja08] [Ko10a] Berkeley View of Cloud Computing,” UC Berkeley Reliable Adaptive Distributed Systems Laboratory, 2009. BITKOM: Cloud Computing – Was Entscheider wissen müssen. BITKOM Leitfaden, 2010. BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter. Bundesamt für Sicherheit in der Informationstechnik, Bonn, September 2010. Catteddu, D.; Hogben, G.: Cloud Computing - Benefits, risks and recommendations for information security. European Network and Information Security Agency (ENISA), 2009. Christmann,S., Hilpert, H., Thöne, M., and Hagenhoff, S., “Datensicherheit und Datenschutz im Cloud Computing – Risiken und Kriterien zur Anbieterauswahl,“ HMD- Praxis der Wirtschaftsinformatik, Heft 275, Oktober 2010, S.62-70. Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing V2.1. Cloud Security Alliance (CSA), Dezember 2009. Distributed Management Task Force (DMTF) “Interoperable Clouds,” Whitepaper from the Open Cloud Standards Incubator, 2009. Distributed Management Task Force (DMTF) “Architecture of Managing Clouds,” Whitepaper from the Open Cloud Standards Incubator, 2010. EuroCloud: Cloud Computing, Recht, Datenschutz & Compliance. Leitfaden des EuroCloud Deutschland_eco e. V., Köln, November 2010. Glaeser, L., Laudel. G., Experteninterviews und qualitative Inhaltsanalyse: als Instrumente rekonstruierender Untersuchungen Vs Verlag; Auflage: 4. Auflage, 2010. Grance, T.; Mell, P.: The NIST definition of Cloud Computing. National Institute of Standards and Technology (NIST), Juli 2009, http://csrc.nist.gov/groups/SNS/cloudcomputing/cloud-def-v15.doc, abgerufen am: 31.12.2010. Günther, O et. al.: Application Service Providers: Angebot, Nachfrage und langfristige Perspektiven. In. WIRTSCHAFTSINFORMATIK, 2001 Ausgabe Nr.: 2001-06. Hilley, D.: Cloud Computing: A Taxonomy of Platform and Infrastructure-level Offerings. CERCS Technical Report, April 2009. Hoefer, C.N; Karagiannis, G.: Taxonomy of cloud computing services. IEEE Globecom 2010 Workshop on Enabling the Future Service-Oriented Internet. Hay, B.; Nance, K.; Bishop, M.: Storm Clouds Rising: Security Challenges for IaaS Cloud Computing, Proceedings of the 44th Hawaii International Conference on System Sciences 2011. Hoch, D.J., and Freking, U., „Cloud Computing, SaaS und SOA als Bausteine im Outsourcing der Zukunft,“ McKinsey on the 7. Entscheiderforum Outsourcing Bad Homburg v.d.Höhe, November 2009. Iyer, B.; Henderson, J.C.: Preparing for the future: Understanding the seven capabilities of Cloud Computing. MIS Quarterly Executive Vol. 9, No. 2, 2010. Jaeger, P.T.; Lin, J.; Grimes, J.M.: Cloud Computing and Information Policy: Computing in a Policy Cloud?. Journal of Information Technology & Politics, Vol. 5(3), 2008. Koehler, P., Anandasivam, A., Dan, M.A., Weinhardt, C., „Customer heterogeneity and tariffs biases in Cloud Computing“, ICIS, 2010. 174 [Ko10b] Koehler, P., Anandasivam, A., Dan, M.A., Weinhardt, C., „Cloud Services from a Consumer Perspective“, AMCIS, 2010. [La10] Lackermair, G., Strahringer, S. and Mandl, P., “Dynamically Scalable Architectures for E-Commerce;” MKWI 2010 – E-Commerce und E-Business, 2010. [Le09] Lehmann, S., and Buxmann, P., “Pricing Strategies of Software Vendors,” Business Information Systems Engineering (1:6), pp. 452-462, 2009. [Le10] Leimeister, S.; Böhm, M.; Riedl, C.; Krcmar, H.: The Business Perspective of Cloud Computing: Actors, Roles, And Value Networks. 18th European Conference on Information Systems ECIS, 2010. [LC10] Leong, L., and Chamberlin, T., „Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting“. Gartner RAS Core Research, December 2010. [Li10] Li, A., Yang, X., Kandula, S., and Zhang. M., “CloudCmp: Comparing Public Cloud Providers,” Internet Measurement Conference, Nov 2010. [Ma10] Martens, B., Teuteberg, F., and Gräuler, M., „Datenbank und Reifegradmodell für die Auswahl und Bewertung von Cloud-Computing-Services,“ HMD-Praxis der Wirtschaftsinformatik, Heft 275, S.52-61, 2010. [Ma11] Martens, B., Teuteberg, F. and Gräuler, M., “Design and Implementation of a Community Platform for the Evaluation and Selection of Cloud Computing Services: A Market Analysis,” in Proceedings of the 19th European Conference on Information Systems, Helsinki, 2011. [Op09] Opencloudmanifesto.org „Open Cloud Manifesto -Dedicated to the belief that the cloud should be open,” www.opencloudmanifesto.org, 2009. [Pe09] Peng J. et. al.: Comparison of Several Cloud Computing Platforms. Second International Symposium on Information Science and Engineering, IEEE 2009. [Pr09] Pring, B., Brown, R. H., Frank, A., Hayward, S. and Leong, L., “Forecast: Sizing the Cloud; Understanding the Opportunities in Cloud Services,” 2009. [PO09] Prodan, R; Ostermann, S.: A Survey and Taxonomy of Infrastructure as a Service and Web Hosting Cloud Providers. IEEE/ACM International Conference on Grid Computing, 2009. [Ri09] Rimal, B. et. al.: A Taxonomy and Survey of Cloud Computing Systems. Fifth International Joint Conference on INC, IMS and IDC, IEEE, 2009. [RZ11a] Repschläger, J.; Zarnekow, R.: Cloud Computing in der IKT-Branche: Status-quo und Entwicklung des Cloud Sourcing von KMUs in der Informations- und Kommunikationsbranche in der Region Berlin Brandenburg, Studie des IKMLehrstuhls der TU-Berlin und dem Verband der Software-, Informations- und Kommunikations-Industrie in Berlin und Brandenburg (SIBB e.V.), 2011. [RZ11b] Repschlaeger, J., and Zarnekow, R., „Umfrage zur Anbieterauswahl und Markttransparenz in der Cloud,“ survey from the technical university Berlin within the IT Operations Day, 2011. [Ru10] Russell, S., Yoon, V., and Forgionne, G., “Cloud-based decision support systems and availability context: the probability of successful decision outcomes”, Information Systems and eBusiness Management, Vol.8, Iss. 3, p.189-205, 2010. [Sa11a] SaaS-EcoSystem: SaaS-EcoSystem Check-Liste. SaaS-EcoSystem e. V., 2011. http://www.saasecosystem.org/trust-in-cloud/checkliste/, aufgerufen am 19.04.2011. 175 [Sa11b] Saunders, C.: MIS Journal rankings. http://ais.affiniscape.com/displaycommon.cfm?an=1&subarticlenbr=432. [Sa10] Saya, S., Pee, L.G., and Kankanhalli, A.,“The impact of insitutional influrences on perceived technological characteristics and real options in Cloud Computing adoption”, ICIS, 2010. [Sc10] Schwarz, A. et. al.: A Conjoint Approach to Understanding IT Application Services Outsourcing. Journal of the Association for Information Systems, Vol. 10: Iss. 10, Article 1, 2010. [SH09] Schrader, U.; Hennig-Thurau, T.: VHBJOURQUAL2. Business Research 2(2):180– 204, 2009. [Ta10] Talukder, A.K., Zimmerman, L., and Prahalad, H.A., “Cloud Economics: Principles, Costs, and Benefits,” in Cloud Computing: Principles, Systems and Applications, N. Antonopoulos and L. Gillam (eds.), Springer-Verlag London, pp. 343-360, 2010. [Th09] The Open Group, “Cloud Computing Business Scenario Workshop,” T. Blevins, D. Lounsbury, M. Kirk, and C. Harding, Report published by the Open Group, August 2009. [Ts10] Tsvihun, I.; Stephanow, P.; Streitberger, W.: Vergleich der Sicherheit traditioneller IT-Systeme und Public Cloud Computing Systeme. Fraunhofer-Institut für sichere Informationstechnologie (SIT), Juli 2010. [Ts08] T-Systems „White Paper Cloud Computing. Alternative sourcing strategy for business ICT,” T-Systems Enterprise Services GmbH, 2008. [Va09] Vaquero, L.M.; Merino, L.M.; Caceres, J.; Lindner, M.: A Break in the Clouds: Towards a Cloud Definition. ACM SIGCOMM Computer Communication Review Volume 39, Nr. 1, 2009. [VJ10] Velton, C.; Janata, S.: Cloud Vendor Benchmark 2010 Cloud Computing Anbieter im Vergleich Deutschland. Experton Group AG, 2010. [Wa08] Wang, L., and Laszewski, G.v., “Scientific Cloud Computing: Early Definition and Experience,” in IEEE International Conference on High Performance Computing and Communications, Dalian, China, 2008. [We09] Weinhardt, C.; Anandasivam, A.; Blau, B.; Borissov, N.; Meinl, T.; Michalk, W.; Stößer, J.: Cloud-Computing – Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete. In: Wirtschaftsinformatik, Nr. 5, 2009, S.453-462. [WW02] Webster, J.; Watson, R.T.: Analyzing the past to prepare for the future: Writing a literature review. MIS Quart 26(2):13–23, 2002. [YT09] Yang, H.; Tate, M.: Where are we at with Cloud Computing?: A Descriptive Literature Review. 20. Australasian Conference on Information Systems, Melbourne, 2009. 176 Assessing Process Models with Cognitive Psychology Stefan Zugal, Jakob Pinggera, Barbara Weber {stefan.zugal, jakob.pinggera, barbara.weber}@uibk.ac.at Abstract: The importance of a business process model to be understandable to its reader is widely acknowledged. In this vein, several approaches to assess and improve understandability exist, such as theoretical quality frameworks, modeling guidelines and process model metrics. In this paper we propose to investigate the issue of understandability from the angle of cognitive psychology. To this end, we discuss how the cognitive process of inference acts as a central process of problem solving. In particular, we illustrate in how far chunking, computational offloading and external memory might have an impact on the understandability of process models. Our propositions are theory-based so far and will serve as basis for planned empirical investigations, as discussed in the research agenda. Keywords: Business Process Modeling, Model Understandability, Cognitive Psychology. 1 Introduction In order to support the analysis and design of, for example, process-aware information systems, service-oriented architectures and web services, business process models or process models for short, are employed [RM11]. Especially process models used in project phases that are concerned with requirement documentation are needed to be intuitive and easy to understand [WW02]. As consequence, various process modeling languages have been proposed, each one of them claiming superiority, cf. [FMR+ 09]. To contribute to an objective discussion, we employ cognitive psychology as tool for assessing and discussing the understandability of process models. More specifically, we embed the concept of inference as central process for problem solving in the context of business process modeling. The remainder of this paper is structured as follows. Section 2 discusses related work. Then, Section 3 introduces concepts from cognitive psychology and puts them in the context of business process modeling. Finally, Section 4 summarizes the findings and concludes the paper with a research agenda. 2 Related Work The understandability of process models is approached from various angles. For instance, in [BRU00], a theoretical point of view is chosen. Complementary, several studies report from empirical investigations. Most works thereby employ the concept of 177 metrics computed on structural aspects of the process model to assess understandability, e.g., [MRC07, VRvdA08, RM11, Car06, MMRS09]. An overview of metrics from software engineering, adapted to business process models can be found in [CMNR06, GL06]. Another interesting work to be mentioned is [MRvdA10], in which empirically validated guidelines for process modeling with the aim to improve understandability are presented. Common to all these approaches is that the model is in the focus of investigation. In our work, however, we use cognitive psychology to focus on the interplay of model and human to examine understandability. 3 Cognitive Concepts for Understanding Process Models Basically, three different problem-solving “programs” or “processes” are known from cognitive psychology: search, recognition and inference [LS87]. Search and recognition allow for the identification of information of rather low complexity, i.e., locating an object or the recognition of patterns. Most conceptual models, however, go well beyond complexity that can be handled by search and recognition. Here, the human brain as “truly generic problem solver” [Tra79] comes into play. Thereby, cognitive psychology differentiates between working memory that contains information that is currently being processed, as well as long-term memory in which information can be stored for a long period of time [PTTG03]. Most severe, and thus of high interest and relevance, are the limitations of the working memory. As reported in [Mil56], the working memory can not hold more than 7±2 items at the same time. In addition, information held in the working memory decays after 18–30 seconds if not rehearsed [Tra79]. To illustrate how severe these limitations are, consider the sequence A-G-K-O-M-L-J. The average human mind is just capable of keeping this sequence in working memory, and, after 18–30 seconds the sequence will be forgotten. The importance of the working memory has been recognized and led to the development and establishment of Cognitive Load Theory (CLT), meanwhile widespread and empirically validated in numerous studies [Ban02]. Theories of CLT revolve around the limitations of the working memory and how these limitations can be overcome—especially the second question is of interest for the understandability of process models. Hence, subsequently, we will discuss three strategies for dealing with the working memory’s limits. First, we will discuss the chunking of information. Second, we will show how process models can support inference through computational offloading. Third, we will introduce external memory, which allows to free resources in the working memory. Chunking and Schema Acquisition. Information is believed to be memorized in interconnected schemata rather than in isolation [Gra07]. Those schemata, which are stored in long-time memory, can be used to aggregate information and handle it as a “chunk” of information in the working memory. Each schemata requires only one slot in working memory when used, hence mental effort is effectively reduced, cf. [New90, CWWW00, Gra07]. The process of aggregating information to a chunk using a schema, in turn, is referred to 178 as “chunking” [Gra07]. To illustrate how chunking actually influences the understandability of business process models, an example is provided in Figure 1. An unexperienced reader may, as shown on the left hand side, use three chunks to store the process fragment: one for each XORgateway and one for activity A. In contrast, an expert may, as shown on the right hand side, recognize this process fragment as a pattern for making activity A optional. In other words, in her long-time memory a schema for optional activities is present, thereby allowing her to store the entire process fragment in one slot in the working memory. A A or in Memory Figure 1: Chunking of an Optional Activity Computational Offloading. In contrast to chunking, which is highly dependent on the internal representation of information, i.e., how the reader organizes information in his mind, computational offloading highly depends on the exact external presentation of the business process model, i.e., visualization of the process model. In particular, computational offloading “refers the extent to which differential external representations reduce the amount of cognitive effort required to solve information equivalent problems” [SR96]. In other words, an external representation may provide features that help the reader to extract information. Instead of computing and inferencing respective information in the modeler’s mind, information can, as in the process of recognition, more or less be “read-off” [SR96]. To put computational offloading into the context of business process modeling, a simple example illustrating the described phenomenon is shown in Figure 2. The illustrated process models are information equivalent, i.e., the same execution traces can be produced based on both Model A and Model B. However, Model A is modeled in BPMN, whereas for Model B the declarative modeling language ConDec [Pes08] was used (for a detailed explanation of declarative process models we refer to [Pes08, MPvdA+ 10]). Consider the task of listing all execution traces that can be inferred from the process model. A reader familiar with BPMN will probably infer within a few seconds that Model A supports execution traces <A, B, D> and <A, C, D>. Such information is easy to extract as BPMN provides an explicit concept for the representation of execution sequences, namely sequence flows. Thus, for identifying all possible execution traces, the reader simply follows the process model’s sequence flows—the computation of all execution traces is offloaded to the process model. In contrast, for Model B, no explicit representation of sequences is present. Rather, constraints define the interplay of actions and do not necessarily specify sequential behavior. Thus, the reader cannot directly read off execution traces, but has to interpret the constraints in her mind to infer execution traces. In other words, process model B, while information equivalent to Model A, does not provide computational of- 179 floading for extracting execution traces. Consequently, even for a reader experienced with ConDec, listing all supported traces is far from trivial. ) Model B a) Model A 0 1 B B A D 1 1 A D 0 1 C C Figure 2: Computational Offloading External Memory. Finally, we would like to introduce another mechanism that is known for reducing mental effort, i.e., the amount of working memory slots in use. In particular, we will discuss the concept of external memory in the context of business process models. An external memory is referred to any information storage outside the human cognitive system, e.g., pencil and paper or a black board [Swe88, Tra79, SR96, LS87]. Information that is taken from the working memory and stored in an external memory is then referred to as cognitive trace. In the context of a diagram, a cognitive trace would be to, e.g., mark, update and highlight information [SR96]. Likewise, in the context of process modeling, the model itself may serve as external memory. When interpreting a process model, marking an activity as executed while checking whether an execution trace is supported, can be seen as leaving a cognitive trace. For the illustration of external memory and cognitive traces, consider the process model shown in Figure 3. Assuming the reader wants to verify, whether execution trace <A, D, E, F, G, H> is supported by the process model. So far, as indicated by the bold path and the position of the token, she has “mentally executed” the activities A, D, E, F and G. Without the aid of external memory, she will have to keep in the working memory, which activities have been executed, i.e., sub-trace <A, D, E, F, G>, as well as the position of the token within the process instance. By writing down the activities executed so far, i.e., transferring this information from working memory to external memory (e.g., piece of paper), load on working memory is reduced. In addition, the process model even allows to store the “mental token”—either by simply putting a finger on the respective part of the process model or by marking the location of the token, as shown in Figure 3. 4 Summary and Research Agenda In this paper we discussed the concept of inference from cognitive psychology in the context of business process modeling. In particular, we described how chunking, computational offloading and external memory can lower mental effort and, in turn, support inference and facilitate the understanding of a process model. We acknowledge that this approach is still work in progress and conclude with identifying 180 B A C F D E G Figure 3: External Memory a research agenda guiding our future research. First and foremost, we are planning to validate the described concepts for process models, i.e., to verify whether the expected effects can be observed in practice. It is assumed that effects are highly dependent on the exact representation of information, e.g., computational offloading may work differently in BPMN models than in ConDec [Pes08] models. Hence, we will start validation using wellknown languages like BPMN and then investigate in how far findings can be generalized to other modeling languages like ConDec. Second, after concepts have been validated, we envision two major directions. On the one hand, as motivated in the discussion, we aim at contributing to an objective discussion about the superiority of process modeling languages. Validated concepts will give us then a tool to assess or predict the understandability of a process model. Such insights may be then used to guide the developement and improvement of process modeling languages. On the other hand, we plan to use the introduced concepts to systematically develop software that supports the understandability of process models. More specifically, as soon as the cognitive processes of understanding a process model are well enough understood, they can be used to systematically analyze shortcomings of process modeling languages and to provide appropriate computer-based support for compensating those shortcomings. References [Ban02] Maria Bannert. Managing cognitive load—recent trends in cognitive load theory. Learning and Instruction, 12(1):139–146, 2002. [BRU00] Jörg Becker, Michael Rosemann, and Christoph Uthmann. Guidelines of Business Process Modeling. In Business Process Management, Models, Techniques, and Empirical Studies, pages 30–49, London, UK, 2000. Springer-Verlag. [Car06] Jorge Cardoso. Process control-flow complexity metric: An empirical validation. In Proc. IEEE SCC ’06, pages 167–173, 2006. [CMNR06] Jorge Cardoso, Jan Mendling, Gustav Neumann, and Hajo A. Reijers. A Discourse on Complexity of Process Models. In BPM’06, pages 117–128, 2006. [CWWW00] Andrew W. Crapo, Laurie B. Waisel, William A. Wallace, and Thomas R. Willemain. Visualization and the process of modeling: a cognitive-theoretic view. In Proc. KDD ’00, pages 218–226, 2000. 181 [FMR+ 09] Dirk Fahland, Jan Mendling, Hajo A. Reijers, Barbara Weber, Mathias Weidlich, and Stefan Zugal. Declarative versus Imperative Process Modeling Languages: The Issue of Understandability. In Proc. EMMSAD ’09, pages 353–366, 2009. [GL06] Volker Gruhn and Ralf Laue. Complexity metrics for business process models. In Proc. BIS ’06, pages 1–12, 2006. [Gra07] Peter Gray. Psychology. Worth Publishers, 2007. [LS87] Jill H. Larkin and Herbert A. Simon. Why a Diagram is (Sometimes) Worth Ten Thousand Words. Cognitive Science, 11(1):65–100, 1987. [Mil56] George Miller. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, 63(2):81–97, 1956. [MMRS09] Joachim Melcher, Jan Mendling, Hajo A. Reijers, and Detlef Seese. On Measuring the Understandability of Process Models. In Proc. BPM Workshops ’09, pages 465– 476, 2009. [MPvdA+ 10] Marco Montali, Maja Pesic, W.M.P. van der Aalst, Federico Chesani, Paola Mello, and Sergio Storari. Declarative Specification and Verification of Service Choreographies. ACM Trans. Web, 4(1):1–62, 2010. [MRC07] Jan Mendling, Hajo A. Reijers, and Jorge Cardoso. What Makes Process Models Understandable? In Proc. BPM ’07, pages 48–63, 2007. [MRvdA10] Jan Mendling, Hajo A. Reijers, and Wil M. P. van der Aalst. Seven process modeling guidelines (7PMG). Information & Software Technology, 52(2):127–136, 2010. [New90] Allen Newell. Unified Theories of Cognition. Harvard University Press, 1990. [Pes08] Maja Pesic. Constraint-Based Workflow Management Systems: Shifting Control to Users. PhD thesis, TU Eindhoven, 2008. [PTTG03] Fred Paas, Juhani E. Tuovinen, Huib Tabbers, and Pascal W. M. Van Gerven. Cognitive Load Measurement as a Means to Advance Cognitive Load Theory. Educational Psychologist, 38(1):63–71, 2003. [RM11] Hajo A. Reijers and Jan Mendling. A Study into the Factors that Influence the Understandability of Business Process Models. SMCA, 41(3):449–462, 2011. [SR96] Mike Scaife and Yvonne Rogers. External cognition: how do graphical representations work? Int.J. Human-Computer Studies, 45(2):185–213, 1996. [Swe88] John Sweller. Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2):257–285, 1988. [Tra79] William J. Tracz. Computer programming and the human thought process. Software: Practice and Experience, 9(2):127–137, 1979. [VRvdA08] Irene Vanderfeesten, Hajo A. Reijers, and Wil M. P. van der Aalst. Evaluating workflow process designs using cohesion and coupling metrics. Comput. Ind., 59(5):420– 437, 2008. [WW02] Yair Wand and Ron Weber. Research Commentary: Information Systems and Conceptual Modeling—A Research Agenda. ISR, 13(4):363–376, 2002. 182 Eye Tracking Experiments in Business Process Modeling: Agenda Setting and Proof of Concept Frank Hogrebe1, Nick Gehrke2, Markus Nüttgens3 1 Hessische Hochschule für Polizei und Verwaltung, Fachbereich Verwaltung, D- 65197 Wiesbaden 2 3 Nordakademie, Hochschule der Wirtschaft, Köllner Chaussee 11, D-25337 Elmshor Universität Hamburg, Lehrstuhl für Wirtschaftsinformatik, Von-Melle-Park 5, D-20146 Hamburg Abstract. For almost all applications there is a need to judge business process models by user´s perspective. This paper presents first facts and findings how the eye tracking method can contribute to a deeper empirical understanding and evaluation of user satisfaction in business process modeling. The method of eye tracking is used in order to check subjective perceptions of users through objective measurement. The experimental investigation is done using two variants of the widespread business process modelling notation “Event-driven Process Chain (EPC)”. Keywords: eye tracking, user satisfaction, event-driven process chain (EPC) 1 Introduction User satisfaction is one of the most widely researched topics in the information systems field [ANC08], [A03]. There are strong relationships between user satisfaction and intended use or actual use of information systems [ANC08, p.44]. The paper focuses on user-based requirements in business process modeling. In order to be able to judge subjective appraisals of test users and real-life users through objective measurements, the method of eye tracking is used in our experiment. For the evaluation of requirements of user satisfaction in business process modeling we focused on, a research framework is developed and used as part of an experiment. Due to the fact, that event-driven process chains (EPC) are still establish as a widespread notation in business process modeling, we used two variants of the EPC to show the prospects and limitations of our approach. 2 Eye Tracking Technique Eye tracking is a technique with which the course of a person's vision when viewing an object, model or an application (investigation objects) can be measured [RP07]. In the taxonomy of research methods, eye tracking is assigned to the user-oriented 183 methods [Y03, p.125]. In the combination of eye tracking and surveys, survey results are supplemented through quantitative eye tracking data. The test person comments on his or her activities, feelings and thoughts in the use of the object of investigation (qualitative aspect). This methodological approach is to be transferred in this investigation to the measurement and analysis of the user satisfaction in business process modeling. 3 User Satisfaction Eye Tracking Experiment 3.1 Research Framework and Hypotheses The research framework has the aim, to create a framework for designing experiments measuring the user satisfaction by combining surveys and eye tracking methods. Our aim in this experiment is to compare the user satisfaction regarding two semiformal modeling notations as the test case. We developed the following basic hypothesis (H1 – H3) for this comparison: H1: Seven user-related requirements deducted from our literature review are acknowledged by users (editors and recipients). H2: Seven requirements are appropriate criteria to check subjective assessments of users with objective measurements of experiments. H3: Eye tracking is an appropriate method for measuring and judging user-related requirements related to the user satisfaction in business process modeling. Table 1. Research Framework for the empirical study Requirements Understanding Completeness Easy to use Usefulness Timeliness Flexibility Accuracy Subjective Perception (Assessment of users in the survey) Users have been asked: the variant of the modeling language is easy to understand? Users have been asked: the variant of the modeling language is complete? Users have been asked: the variant of the modeling language is easy to use? Users have been asked: the variant of the modeling language is useful? Users have been asked: the variant of the modeling language is time saving? Users have been asked: the variant of the modeling language is flexible? Users have been asked: the variant of the modeling language is accurate? Measurement (Experiment with users) A graphical representation of a process is shown to the users and specific questions are asked. Number of false answers is counted. Users have to model a pre-defined process. It is noted if users are capable to model the process (Editors) Users have to model a pre-defined process. Number of modeling errors is counted (editors). In a given graphical representation of a process users need to find a pre-defined object. The following is measured: *Numbers of fixations with eye tracking methods *Length of fixation with eye tracking methods. The more and the longer fixations are, the more the effort and the worst the balance between effort and utility. Users have to model a pre-defined process. The time needed is recorded (editors). No measurement since users considered this requirement to be less important (rank 6 of 7). No measurement since users considered this requirement to be less important (rank 7 of 7). Due to the fact, that event-driven process chains (EPC) are still establish as a widespread notation in business process modeling, we used two variants of the EPC to show the prospects and limitations of our approach. In our experiment two variants of the event-driven process Chain (EPC) are used for validating the seven requirements: 184 the extended EPC (eEPC) and the object oriented EPC (oEPC) [SNZ97]. Our investigation is based on 24 users (12 editors and 12 recipients of models). In each group 6 users have been students and 6 have been employees of a public administration. We use as our test case graphical representation of public administration processes, because there are good experiences about the notations in this area (see survey, [anonymous]). The users have been asked to subjectively assess the modeling languages regarding the seven requirements. Furthermore, we did experiments with the users like measuring time to model a process (for editing users) or counting the number of errors a user was able to find in a model (for recipient users). Another example is measuring the length of fixations during solving a specific task by using eye tracking (editors and recipients). All requirements have been mapped in order to measure how the requirements are achieved by the two variants of the modeling language. After that we compare the results of the subjective assessment and the objective experiment for both, requirements and variants. As a result of our investigation, the most important requirements were ‘understanding’ (editors: 8, recipients: 11), ‘completeness’ (editors: 7, recipients: 6) and ‘easy to use’ (editors: 5, recipients: 7). In this context, we asked if a user missed an important requirement but none of the 24 users answered ‘yes’. Thus, we conclude that the seven requirements used in our investigation are sufficient. Hypothesis 1 can be considered to be confirmed in the context of our experiment. Table 4 depicts the research framework for our empirical study of the userrelated requirements. The column ‘measurement’ describes the experiment used for the specific requirement. 3.2 Statistical Analysis In the following section we analyze the data gathered during our survey regarding the requirements. For all requirements interviewees could answer with the following options: I fully agree (=4), I agree partially (=3), I doubt to agree (=2), I do not agree at all (=1) for each variant of the modeling language (eEPC and oEPC). Due to missing answers the sample size could be less than 12. Table 2 depicts basic statistic ratios regarding the assessment of the requirements by the interviewees during the survey. Obviously, all requirements – except the requirement ‘accuracy’– got a better average assessment regarding the oEPC. The requirement ‘accuracy’ has been assessed equally. The correlation of the assessments between eEPC and oEPC (right table) only reveal a significant (negative) relationship [> (-) 0.5] for the requirement ‘time saving’. That means interviewees assessing one modeling language as time saving tend to assess the other language as less time saving. In the following we want to verify if differences in the assessments of the interviewees are significant regarding each requirement. For this reason we conducted a t-Test testing for different means in dependent samples. Table 3 shows the results of the statistic test. The column ‘Sig. (2-tailed)’ shows the significance level of the difference of means regarding the assessment of the interviewees for each requirement (meaning H0: eEPC=oEPC; H1: oEPC#eEPC). But we want to focus on the hypothesis that one modeling language is better than the other one. Thus, we also test H0: eEPC=oEPC; H1: oEPC>eEPC to validate if the oEPC language dominates the eEPC variant (see 185 column ‘Sig. (1-tailed)’). Since we test H0: eEPC=oEPC; H1: oEPC>eEPC the confidence level is always half the confidence level of column ‘Sig. (2-tailed)’. As a result, we can see that the requirement ‘flexibility’ has been considered to be better in respect to the oEPC language on a 95% confidence level whereas the requirements ‘easy to use’ and ‘usefulness’ are significant on a 90% level. In the same manner we analyzed the data of the survey we now want to consider the results of the experiments as depicted in table 4. Please note that Pair 4 and 5 both are linked to the requirement ‘usefulness’ since the data represents on the one hand the number of fixations and on the other hand the length of the fixations. Table 2. Statistic ratios regarding the assessment of requirements by interviewees Paired Samples Statistics Mean N air 1 E C easy-to-use oE C easy-to-use air 2 E C Flexi ility oE C Flexi ility air air air air air 2 Std De iation 00 12 12 11 Std Error Mean 000 8 8 000 22 2 Paired Samples Correlations N 11 E C accuracy oE C accuracy E C understandin oE C understandin E C completeness oE C completeness E C timeliness oE C timeliness E C usefulness oE C usefulness 20 2 2 11 11 2 12 12 1 12 12 2 11 18 11 2 82 11 11 8 1 92 8 8 1 009 1 982 2 19 1 9 1 2 2 1 22 0 22 29 20 C C C C Corr Si air 1 air 2 air air E E E E easy-to-use oE C easy-to-use flexi ility oE C flexi ility accuracy oE C accuracy understandin oE C understandin 12 11 11 0 12 - 120 air air air E C completeness oE C completeness E C timeliness oE C timeliness E C usefulness oE C usefulness 12 11 11 9 2 0 91 - 88 2 1 11 12 0 Table 3. t-tests of the assessments of the interviewees for each requirement (different means) Paired Samples Test air 1 air 2 air air air air air E E E E E E E aired Differences 90 Std Std Error o er pper Mean De iation Mean 8 22 0 0 809 2 -1 0 8 - 19 000 1 000 02 -2 0 218 - 1 1 1 -1 8 2 1 - 99 2 1 2 -1 1 0 10 12 -1 111 021 easy-to-use - oE easy-to-use flexi ility - oE flexi ility accuracy - oE accuracy understandin - oE understandin completeness - oE completeness timeliness - oE timeliness usefulness - oE usefulness t -1 8 -2 09 000 -1 1 9 - 92 -9 9 -1 Si (2- Si (1df tailed) tailed) 11 1 08 10 02 01 10 1 000 00 11 2 1 11 0 2 2 10 0 180 10 111 0 inner oE oE NA oE oE oE oE Table 4. Statistical ratios of the experiments regarding the requirements Paired Samples Statistics air 1 E oE air 2 E oE air E oE air E oE air E oE understandin errors understandin errors easy-to-use errors easy-to-use errors timeliness time timeliness time usefulness Num erOfFixations usefulness Num erOfFixations usefulness en thOfFixations usefulness en thOfFixations Mean Std Std Error N De iation Mean 2 0 2 92 10 08 2 8 9 00 00 29 1 2 2 1 8 92 1 1 92 12 12 12 12 12 12 12 12 12 12 11 18 12 09 2 89 2 09 28 1 09 89 8 0 18 29 18 1 10 2 1 1 Paired Samples Correlations N Corr Si air 1 E oE air 2 E use air E air E oE air E oE understandin errors understandin errors easy-to-use errors oE easy-toerrors timeliness time usefulness Num erOfFixations usefulness Num erOfFixations usefulness en thOfFixations usefulness en thOfFixations 12 - 11 12 22 0 12 2 2 12 - 0 12 21 8 2 Regarding table 4 please note that – compared to the assessments of the interviewees – small values are better than big ones (e.g. less errors are better than more errors or less time consuming is better than more time consuming). Obviously, regarding the 186 8 means the oEPC language performs better for all requirements than the eEPC variant except for the requirement ‘understanding’. Focusing on ‘understanding’ one can see that users answered with fewer errors considering the eEPC. In this context, we reason that eye tracking is an appropriate method to measure and assess requirements for user satisfaction in business process modeling in our experiment. Therefore, Hypothesis 3 can be considered to be confirmed. T-tests regarding the differences of the means of the measurements reveal that the oEPC variant dominates significantly the eEPC variant (Table 5). Only the requirement ‘understanding’ cannot be considered significant. The requirements ‘easy to use’ and ‘timeliness’ are significant on a 95% level (see column Sig. (2-tailed)). The two measurements for ‘usefulness’ are significant only on a 90% level. Table 8 does not contain the requirement ‘completeness’ since all users where able to model the predefined process in the appropriate experiment with the eEPC and the oEPC variant. Thus, the requirement ‘completeness” remains undecided. Table 5. t-tests of the experiments / measurements for top 5 requirements Paired Samples Test aired Differences 90 Confidence Inter al Mean air 1 air 2 air air air E oE E use E oE E oE E oE understandin errors understandin errors easy-to-use errors - oE easy-toerrors timeliness time timeliness time usefulness Num erOfFixations usefulness Num erOfFixations usefulness en thOfFixations usefulness en thOfFixations Std De iation Std Error Mean - 2 0 00 92 o er 22 pper 2 98 - 1 09 1 91 2 10 11 8 1 2 2 00 1 2 df -1 0 12 91 t -2 1 Si (2-tailed) 11 Si (1tailed) 2 9 0 0 0 8 11 01 91 8 1 11 12 00 0 2 1 1 11 1 0 inner E oE oE oE oE After having analyzed the results of the survey and the experiments separately, we now want to focus on a comparison of both as an overall result. Table 6 shows the results of this comparison. Table 6. Comparison of survey and results, * 90% significance, ** 95% significance Requirement "Winner" survey "Winner“ experiment Understanding Completeness Easy to use Usefulness Timeliness oEPC oEPC oEPC* oEPC* oEPC eEPC N/A oEPC** oEPC* oEPC** Flexibility oEPC** No measurement Accuracy N/A No measurement Comment no significance no significance significant for oEPC significant for oEPC Experiment significant for oEPC, Survey not significant for oEPC significant for oEPC, no experiment no significance Obviously, a significant result can be detected regarding the requirements ‘easy to use’ and ‘usefulness’. Only significant in one area, but on an average the oEPC dominates regarding the requirement ‘timeliness’. Considering the requirement ‘flexibility’, the oEPC has been significantly assessed better than the eEPC, but we did not conduct an experiment for that requirement. For the requirement ‘accuracy’ we cannot deduct a winner. Furthermore, for the requirements ‘understanding’ and ‘com- 187 pleteness’ there is no significant result. To sum up the oEPC seems to dominate most requirements (often significant). The eEPC variant succumbs or is equal to the oEPC variant. As a result, the literature based common user related requirements are appropriate to check subjective assessments of users in a survey with objective experiments. Therefore, hypothesis 2 can be considered to be confirmed regarding our experiment. 4 Summary of the results The eye tracking method was used for first time in the measurement and assessment of the user satisfaction in business process modeling. In the application case, the eye tracking method was used to visualise objective measurement and progression data, in addition to the survey techniques. The graphical depictions from the eye tracking (heatmaps) were able to visually support the investigation results. The research framework was used on the basis of extended and object-oriented event-driven process chains (eEPC and oEPC). We used always the same modeling tool to minimize external effects when testing our framework (bflow Toolbox [BT10]). To what extent investigations on the basis of other semi-formal modelling languages lead to other results remains reserved for other investigations. The hypotheses (H1 to H3) could be confirmed on the basis of two variants of the event-driven process chain (EPC). To what extent investigations on the basis of other semi-formal modelling languages in the field of business process modeling lead to other results remains to be validated in follow-up investigations. The initial results of this investigation are interesting, in particular with regard to the options to visualise measurement results in the representation of heatmaps. Here, however, further investigations should follow in order to be able to validate the relevance of the eye tracking method for investigations in the research area of information systems moreover. References [A03] Aladwani, A.M.: A Deeper Look at the Attitude-Behavior Consistency Assumption in Information Systems Satisfaction Research. In: The Journal of Computer Information Systems (44:1), (2003), pp. 57--63 [ANC08] Au, N., Ngai, E.W.T., Cheng, T.C.E.: Extending the Understanding of End User Information Systems Satisfaction Formation: An Equitable Needs Fulfillment Model Approach. In: MIS Quarterly Vol. 32 (2008), 1, pp.43—66 [BT10] Bflow Toolbox. www.bflow.org. Accessed 2011-07-31 [RP07] Rosen, D.E., Purinton, E.: Website Design: Viewing the Web as a Cognitive Landscape. In: Journal of Business Research, 57 (2007) 7, pp.787--794 [SNZ97] Scheer, A.W., Nüttgens, M., Zimmermann, V.: Objektorientierte Ereignisgesteuerte Prozeßketten (oEPK) – Methode und Anwendung (in german). In: working paper vol. 141, institute of information systems, (1997), Saarbrücken (germany) [Y03] Yom, M.: Web usability von Online-Shops. Better-Solutions-Verlag Gierspeck, Göttingen (2003) 188 Creative Personality and Business Process Redesign † Kathrin Figl† , Barbara Weber‡ Vienna University of Economics and Business (WU Vienna) kathrin.figl@wu.ac.at ‡ University of Innsbruck barbara.weber@uibk.ac.at Abstract: The purpose of this article is to discuss the influence of creative personality on process redesign. Building on creativity theories stemming from the field of cognitive psychology, we identify important individual factors during process redesign, and hypothesize their contributions to creative process design using a modelling tool. We present an integrated research model and illustrate how we seek to test the model using the Cheetah Experimental Platform. 1 Introduction It has long been recognized that business process redesign and innovation can lead to improved processes and better business performance and customer satisfaction. Process improvement was the number one item for top management according to the Gartner Group in 2010 [Gro10]. In practice, process models are used for analyzing, documenting and improving business processes. They help to identify process weaknesses as well as possible improvement opportunities. An important factor for process improvement are the employees working with the process models. For creating novel and valuable ideas for process redesign human creative ability is needed. Cook describes creativity as “source of competitive strength within organizations” [Coo98, 179]. Companies have to identify their creative potential to enable business innovation. Identifying individual creative potential is relevant for assembling teams and deciding who should be part of a process redesign team. Additionally, creativity training can be of relevance for teams working on processes. Despite increasing consciousness about the need to consider creativity in researching business innovation, most research up to now was undertaken in the field of product innovation. The business process management community has barely recognized the importance of creativity and little research has been undertaken to improve and understand the relationship between creativity and business process redesign. There are few exceptions as for instance Seidel et al. [SR08] who discuss the concept and management of creativity in business process management. Given the high practical relevance of creative process redesign, the aim of this paper is filling that gap by investigating the relationship between individual creativity and business process redesign. More specifically, we address the research question how creative 189 personality style and creative capacity influence creativity in process redesign tasks. 2 Theoretical Background Business Process Redesign. Business process reengineering and continuous process improvement constitute two different ends on a continuum of business process redesign. Business process reengineering refers to “fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measure of performance, such as cost, quality, service and speed” [HC93]. Thereby, business process reengineering largely ignores the existing process and in the most extreme case follows a clean sheet approach creating the redesigned process from scratch. Continuous process improvement, in turn, typically takes existing processes as a starting point and gradually improves them in an incremental manner [Dav93]. While both approaches differ in their focus, both aim at the redesign of existing business processes and lead to a transformation of the original process model (i.e., AS-IS process) into a redesigned version (i.e., TO-BE process) improving one or more performance measures. To achieve this transformation different redesign patterns can be used as for instance cutting non-value adding tasks, changing the order of tasks or automating tasks [RLM05]. Creativity and Creative Personality. Creativity and creative problem-solving form the basis for business innovation and process redesign [MM02]. Similarly to other design activities, there is no single solution and no clear path to a solution in a process redesign task. A creative solution is defined as being both original and novel as well as relevant and valuable in the specific context [Ama83, 358]. When researching creativity three main aspects are relevant: the creative person, the creative process and the creative product [Ama83]. In our study we intend to include all three aspects and examine how creative personality influences the solutions to a process redesign-task (creative product) using a modelling tool (creative process). One of the most influential personality models in the context of creativity is the Adaption-Innovation theory by Kirton [Kir76]. While adaptors tend to “doing things better”, innovators are likely to be “doing things differently” [Kir76, 622]. Adaptors work out few, but realizable solutions, they pay attention to details and work out the solution incrementally with well-known techniques [FH92, 967]. In contrast, innovators propose more, but less realistic solutions and might ignore rules and existing paradigms. This distinction directly relates to the continuum between continuous, incremental improvement [Dav93] and radical redesign of processes [HC93]. 3 Research Model and Hypotheses Having laid out the relevant theoretical foundation related to creativity and business process redesign, we will now draw several propositions to suggest which factors will influence business process redesign. Concerning person-related characteristics creative style and creative capacity are two independent dimensions [Kir78, 697] which are both rel- 190 evant for solutions to process improvement tasks. Besides person-related characteristics there are two more factors contributing to the creative process [Ama83]: domain-relevant skills and task motivation. We summarize our expectations about relevant influence factors in light of the theoretical considerations in the research model shown in Figure 1. Figure 1: Research Model The model proposes that the quality of a redesigned model in a process redesign task will be a function of person-related characteristics (style and capacity), process modelling competence (domain-relevant skills) and task motivation. Concerning the influence of creative style we anticipate the following effects: In contrast to innovators, adaptors perceive “boundaries less elastic and permeable” [Kir78, 697]. Therefore, we expect adaptors to make only small, continuous improvements to the model, innovators to radically change the process and do a complete reengineering. Innovators are more likely to “break existing patterns” [Mud95, 167]. As innovators do not pay as much attention to details they might make more syntax errors, but produce more innovative ideas. We state: H1: Higher innovative style is positively associated with the amount of model changes. H2: Higher adaptive style is positively associated with the correctness of model solutions. According to [GT02, 1] there are two basic indicators of creativity: fluency is defined as “the ability to produce quantities of ideas which are relevant to the task instruction” and originality as “the ability to produce uncommon ideas or ideas that are totally new or unique”. We expect creative capacity to positively influence both criteria. Therefore: H3: Creative ability is positively associated with originality and fluency in the redesign. Next, we consider process modelling competence and task motivation. We speculate both factors to contribute to the creative quality of process redesigns in terms of fluency and originality. While lower modelling experience might hinder creative persons from fully unfolding their capacity to provide creative ideas, high task motivation might foster creativity. H4: Process modelling competence is positively associated with originality and fluency in the redesign. H5: Task motivation is positively associated with originality and fluency in the redesign. 191 4 Planned Empirical Study For answering these research questions we are currently conducting an empirical study using the Cheetah Experimental Platform [PZW10]. Cheetah guides participants through a variety of questionnaire parts, offers a tutorial on process modelling and a process modelling tool for the redesign tasks, which logs every modelling action (e.g., adding and deleting of activities) to enable later analysis. The next paragraphs introduce main parts of the experimental design. 4.1 Measurement of Independent Variables Creative Style: Innovative vs. Adaptive Problem-Solving Style (KAI (Kirton AdaptionInnovation Inventory): The Kirton Adaption-Innovation Inventory [Kir76] measures individual problem-solving style relating to the quality of problem solutions. Respondents have to rate themselves on 32 items. It measures three different scales: sufficiency of originality, efficiency and rule governance. Creative Capacity: Abbreviated Torrance Test of Creative Thinking (ATTA): The Torrance Tests of Creative Thinking (TTCT) measures divergent thinking and assesses the quantity and quality of creative ideas. It is a widely used (by over 2000 studies) instrument [GT02]. For the purpose of our study we use the verbal subscale of the abbreviated test version as a screening indicator of creative thinking abilities. The scores in the test are based on fluency (number of ideas) and originality (unusualness of ideas). Process Modelling Competence: Participants are asked about the extent to which they have previously been involved with modelling in education and work. Additionally, we use a test on theoretical knowledge of process modelling developed by [MS08]. Task Motivation: For measuring intrinsic motivation we use three items derived from a scale by [DBW92]. An example item was: ‘I found the tasks of providing improvement ideas for the processes to be enjoyable.’ 4.2 Measurement of Dependent Variables: Process Redesign Experimental Redesign Tasks In our experiment participants are asked to work out improved TO-BE models for two given AS-IS process models. We use 2 measure-invoked redesign tasks [SK10] targeting the measure- (customer) quality for the construction of creative redesign tasks. The two AS-IS models were selected from different domains such that we could expect that they are understandable with no special domain knowledge. In the first task we ask participants to optimize a new check in and guidance service of an airline to best support costumers as well as business interests. The second task asks for a process redesign of a coffee shop service to foster customer satisfaction. Measurement of Process-Redesigns For analyzing the process redesigns we intend to use 192 quantitative as well as qualitative measures. • Change Distance: The amount of process changes can be measured as the number of change operations needed to obtain the redesigned TO-BE process model from the original AS-IS process model. Thereby, this measure considers operations related to the insertion or deletion of activities/edges. • Correctness is assessed in terms of syntax as well as execution semantics. In particular, we measure whether syntactic requirements imposed by BPMN are met, and whether the model is free of behavioral anomalies such as deadlocks. To this end, we apply the soundness criterion for syntactically correct models [van98]. • Creativity of Redesign Ideas is assessed by a team of independent experts according to originality and fluency. We deploy an iterative consensus-building process to ensure validity and reliability of our assessment. 5 Example of Preliminary Analysis Figure 2: Detail of Airport Model and Exemplary Redesigns Data collection is still ongoing and participants are being recruited from modelling courses. We would like to discuss two redesign examples of a process snippet, as can be seen in Figure 2. The study participant with the ‘adaptive solution’ scored low on the AdaptiveInnovative continuum (2.60 on a scale from 1 to 5), the participant with the ‘innovative’ solution scored high (3.49). In the redesign solution we can see, that the ‘adaptor’ simply added one activities to notify the customer if the flight is not delayed, demonstrating incremental improvement. The ‘innovator’ added two activities and he reengineered the complete order of the process. This example would support hypothesis 1, but further data collection and detailed analysis will be needed to test hypotheses. References [Ama83] T. M. Amabile. The social psychology of creativity: A componential conceptualization. Journal of Personality and Social Psychology (1983), 45(2):357–376, 1983. 193 [Coo98] Peter Cook. The creativity advantage - is your organization the leader of the pack? Industrial and Commercial Training, 30:179–184, 1998. [Dav93] T.H. Davenport. Process innovation: reengineering work through information technology. Harvard Business School Press, Boston, MA., 1993. [DBW92] Fred D. Davis, Richard P. Bagozzi und Paul R. Warshaw. Extrinsic and Intrinsic Motivation to Use Computers in the Workplace. Journal of Applied Social Psychology, 22(14):1111–1132, 1992. [FH92] Gordon R. Foxall und Paul M. W. Hackett. The factor structure and construct validity of the Kirton adaption-innovation inventory. Personality and Individual Differences, 13(9):967– 975, 1992. [Gro10] Gartner Group. Leading in Times of Transition: The 2010 CIO Agenda (EXP Premier Report No. January 2010). Bericht, Gartner, Inc., 2010. [GT02] Kathy Goff und E. Paul Torrance. Abbreviated Torrance Test for Adults (ATTA). Manual. Scholastic Testing Service, Bensenville, Illinois, 2002. [HC93] M. Hammer und J. A. Champy. Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business Books, 1993. [Kir76] M. J. Kirton. Adaptors and innovators: A description and measure. Journal of Applied Psychology, 61(5):622–629, 1976. [Kir78] M. J. Kirton. Have adaptors and innovators equal levels of creativity? Reports, 42:695–698, 1978. Psychological [MM02] R. McAdam und J. McClelland. Individual and team-based idea generation within innovation management: organisational and research agendas. European Journal of Innovation Management, 5:86–97, 2002. [MS08] Jan Mendling und Mark Strembeck. Influence Factors of Understanding Business Process Models. In Proc. BIS 2008, Seiten 142–153. Springer, 2008. [Mud95] Samuel Mudd. Kirton adaption-innovation theory: organizational implications. Technovation, 15(3):165–175, 1995. [PZW10] J. Pinggera, S. Zugal und B. Weber. Investigating the Process of Process Modeling with Cheetah Experimental Platform. In Proc. ER-POIS ’10, Seiten 13–18, 2010. [RLM05] H. A. Reijers und S. Liman Mansar. Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics. Omega, 33(4):283– 306, 2005. [SK10] Avraham Shtub und Reuven Karni. Business Process Improvement. In ERP, Seiten 217– 254. Springer US, 2010. [SR08] Stefan Seidel und Michael Rosemann. Creativity Management The New Challenge for BPM. BPTrends, 2008. [van98] W.M.P van der Aalst. The Application of Petri Nets to Workflow Management. JCSC, 8(1):21–66, 1998. 194 Abstractions in Actor and Activity Modeling Matthias Wester-Ebbinghaus, Daniel Moldt University of Hamburg, Department of Informatics Vogt-Kölln-Straße 30, D-22527 Hamburg {wester,moldt}@informatik.uni-hamburg.de Abstract: In this paper we argue that actor-centered models are well suited for sociotechnical systems of systems (like enterprise and especially cross-enterprise scenarios). Results can especially be drawn from the field of multi-agent system modeling. However, existing approaches reveal a lack of possibilities for switching between different levels of abstraction. This does not only concern more or less abstract models for a given situation (model abstraction), but also to have models with actors of varying granularity, including individual as well as collective actors (actor abstraction). We present a modeling approach that addresses both these aspects. It is based on the core concepts of actors and activities and especially the concept of a collective actor is emphasized. For supporting different levels of model abstraction, we present multiple modeling techniques. The semantic core of all models is based on high-level Petri nets, although this is hidden for the more abstract models. 1 Introduction Modern perspectives on software systems (e.g. ultra large scale systems [Nor06] or application landscapes [Mat08]) heavily rely on the concept of systems of systems. Core distinguishing features of systems of systems are the operational as well as managerial independence of component systems. In addition, they are software-intense sociotechnical systems where a suitable joint optimization of social and (software-)technical system parts has to be pursued. Agent-orientation has emerged as a powerful and general conceptual framework for socio-technical systems of systems. Both the idea of independent, loosely-coupled component systems (the agents) and the establishment of system-level/organizational structures are addressed equally [Jen00, Dig09].1 As in a system of systems setting, a component system might be a system of systems itself, approaches for collective agency have been brought forth in recent years (cf. [HMMF08, AG09]). These are motivated by the social and especially organization-theoretic concept of collective actors: Collectivities (networks of social relations between social actors) are Janus-faced, social contexts as well as collective actors that are embedded in more global contexts. Nevertheless, on the modeling side, there still exists what we call an actor abstraction problem as there is a lack of modeling techniques that allow for a seamless integration of 1 Many of the concepts and ideas of agent-orientation nowadays appear in the “guise” of service-oriented systems (cf. concepts like autonomous, intelligent or collaborating services where the service metaphor is quite stressed and the agent metaphor is better suited). However, we will not deepen on this topic in this paper. 195 actors of varying granularity/abstraction. In this paper we present a modeling approach with the specific aim of addressing this problem. Our main goal is to support planning and design of actor systems, possibly including social as well as artificial actors. We address abstraction in two dimensions: (1) more or less abstract models for specific scenarios (model abstraction), (2) possibilities to integrate actors of different abstraction/granularity in scenarios (actor abstraction). For more or less model abstraction, we present three modeling techniques and each of the techniques incorporates the concept of collective actors. 2 Different Levels of Abstraction for Actor/Activity Models So called Actor/Activity-Flow Models provide the semantic core for the more abstract models. They are high-level Petri net models and thus have a precise operational semantic. Figure 1 shows an Actor/Activity-Flow Model of two Collectivity Units. With a Collectivity Unit, we denote an entity that is a context for embedded actors and that may actually be an actor itself. A Collectivity Unit is modeled in terms of actor positions and activity patterns. Actors initiate activities, participate in them and may be added or removed from their positions in the course of activities. In the example, we show two activity patterns transaction and replace-seller for Collectivity Unit A and the associated actor positions seller, buyer, governor and administrator. An activity pattern consists of connected transitions that represent actions. Places connect the transitions in a way to make up the life lines of activity roles (vertically connected) and exchanges between activity roles (horizontally connected). For each activity pattern, we have one role that is the initiating role. In the example we have the two roles sender and receiver for the transaction activity pattern (where the sender is the initiating role) and two exchanges between them (for an item sent and the following acknowledge). The example also includes a second Collectivity Unit B. This Collectivity Unit is actually an actor itself and is embedded in the context of Collectivity Unit A as a buyer.2 The figure exemplifies that collective agency in our model results from what we call role implementation via role implementation. On the level of Collectivity Unit A, there is a buyer actor embedded that implements the role receiver in the context of a transaction activity and thus carries out the actions for receiving an item and for sending an acknowledge. Here however, this actor is itself a Collectivity Unit and in order to implement the role receiver on the next higher system level, there are the two internal roles distributor and inspector. For these internal roles, there are specified several peripheral actions that correspond to (/synchronize with) the actions for the role receiver on the next higher system level. To summarize, Collectivity Unit B implements the role receiver in the context of Collectivity Unit A by means of embedding some actors itself that in turn implement the roles distributor and inspector where peripheral actions synchronize with the actions of the receiver role. In general, such action recursion across system levels can be arbitrarily deep and individual actors (not modeled here) represent the recursion termination. 2 Such hierarchies of Petri nets being embedded in other Petri nets is covered by the high-level Petri net concept of nets-within-nets [Val04] and is for example supported by the Renew tool (www.renew.de). 196 Figure 1: Excerpt from a more complex Collectivity Unit Actor/Activity-Flow Models are quickly becoming large and unhandy. Thus we will present means for abstracting away from details. In the upcoming models, the underlying Petri net semantic is no longer directly visible but it still provides the basis for understanding them. The first abstraction step is in omitting details of activity flows and instead just referring to the roles of activities. Figure 2 shows an example of such an Actor/Activity-Role Model. It is the abstraction of the Actor/Activity-Flow Model from Figure 1. Actor positions are now just associated with activities (initiation, participation, addition, removal associations) and internal details of the activities are hidden. The information revealed is similar to common Use Case Diagrams. However, for our purpose to regard Collectivity Units as collective actors, we need an extension in the form of associations across system levels. We use a notation of combining activity roles via logical operators. Above, we have characterized collective agency basically as role 197 Figure 2: Abstracting away from the activity flows of Figure 1 implementation via role implementation. For Actor/Activity-Role Model models, we introduce AND/XOR configurations. For each AND/XOR configuration, we combine a set of roles of an activity pattern via a logical AND. For each instance (concrete activity) of the activity pattern, these roles together implement exactly one role of a set of roles that are combined with a logical XOR. In the example, it is simply modeled (just as before) that the implementation of the roles distributor and (logical and) inspector of a reception activity of Collectivity Unit B lead to the implementation of the role receiver of a transaction activity of Collectivity Unit A. One might also want to consider additional logical operators for combining roles. For now, we have intentionally chosen the restricted means of AND/XOR configurations here as in our opinion, they lead to simple yet expressive possibilities for cross-level role associations. Two canonical applications are shown in Figure 3. We introduce one further step of abstraction. Instead of regarding singular actor positions and activity patterns, we regard arbitrarily comprehensive actor and activity sets and consequently Actor-/Activity-Set Models. The transition from the former Actor/ActivityRole Models to Actor-/Activity-Set Models is shown in Figure 4. On the top of the figure is (one level of) the previous Actor/Activity-Role Model. A preliminary abstraction step is shown in the middle of the figure where each actor position and each activity pattern is regarded as a singleton actor or activity set respectively. Addition/removal associations are now subsumed under participation associations. Based on this basic Actor-/ActivitySet Model, different more abstract models can be derived. We call these different perspectives on the initial model and we show some of them at the bottom of the figure. For each perspective it is noted which set unions were applied. Here, we distinguish between absolute associations between an actor set A and an activity set B (each sub-set Asub ⊆ A has this association to one of the sub-sets Bsub ⊆ B) and contingent associa- 198 Figure 3: Examples of embedding situations based on AND/XOR configurations Figure 4: Transition from Actor/Activity-Role Models to Actor-/Activity-Set Models tions (for at least one but not for all sub-sets Bsub ⊆ B, there is an association to one of the sub-sets Asub ⊆ A). 199 For Actor-/Activity-Set Models it also has to be taken into account that Collectivity Units can be collective actors. For this purpose, it is no longer regarded which activity roles are cross-level associated but just which activity sets on different levels have which ”interleaving” associations (for example, whether an interleaving is specified for each or just for some activities of an activity set). Due to space limitations, we do not cover the corresponding modeling primitives here. 3 Conclusion In this paper, we present a modeling approach for actor/activity models that explicitly addresses abstraction in two dimensions: (1) more or less abstract models for a given scenario (model abstraction) and (2) more or less actor granularity (actor abstraction). The results we present are part of our ongoing research. We yet have to provide tool support for our modeling approach. Furthermore, up to now the models were mainly used as means to conceptualize quite generic and abstract archetypes of organizational units in multi-level organizational scenarios (cf. [WE10], in german). For the future, we need to validate the practical use of the modeling approach by applying it to real-world scenarios. References [AG09] AOS-Group. Jack Intelligent Agents Team Manual. http://www.aosgrp.com/ documentation/jack/JACK Teams Manual WEB/index.html, 2009. Available at: [Dig09] Virginia Dignum, editor. Handbook of Research on Multi-Agent Systems: Semantics and Dynamics of Organizational Models. Information Science Reference, 2009. [HMMF08] Christian Hahn, Cristian Madrigal-Mora, and Klaus Fischer. A Platform-Independent Metamodel for Multiagent Systems. Autonomous Agents and Multi-Agent Systems, 18(2):239–266, 2008. [Jen00] Nicholas Jennings. On agent-based software engineering. Artificial Intelligence, 177(2):277–296, 2000. [Mat08] Florian Matthes. Softwarekartographie. Informatik-Spektrum, 31(6):527–536, 2008. [Nor06] Linda Northrop. Ultra-Large-Scale Systems: The Software Challenge of the Future. Software Engineering Institute, Carnegie Mellon, 2006. [Val04] Rüdiger Valk. Object Petri Nets: Using the Nets-within-Nets Paradigm. In Jörg Desel, Wolfgang Reisig, and Grzegorz Rozenberg, editors, Lectures on Concurrency and Petri Nets: Advances in Petri Nets, volume 3098 of Lecture Notes in Computer Science, pages 819–848. Springer, 2004. [WE10] Matthias Wester-Ebbinghaus. Von Multiagentensystemen zu Multiorganisationssystemen – Modellierung auf Basis von Petrinetzen. Dissertation, Universität Hamburg, Fachbereich Informatik. Elektronische Veröffentlichung im Bibliothekssystem der Universität Hamburg: http://www.sub.uni-hamburg.de/opus/ volltexte/2011/4974/, 2010. 200 A Generic Multi-purpose Conceptual Model Analysis Approach – Conceptual Specification and Application Sebastian Herwig, Łukasz Lis, Matthias Steinhorst, Jörg Becker, Patrick Delfmann University of Münster European Research Center for Information Systems (ERCIS) Leonardo-Campus 3 48149, Münster Germany {herwig | lis | steinhorst | becker | delfmann}@ercis.uni-muenster.de Abstract: In this paper, we introduce a model analysis approach suitable for multiple analysis purposes. The approach is based on generic graph pattern matching and semantic standardization of model elements. Due to its generic nature, it is applicable to conceptual models of any graph-based modelling technique. Through semantic standardization, the approach relies on unambiguous model contents. Therefore, its focus is on analyses with regards to the structure and contents of conceptual models. 1 Introduction The analysis of conceptual models addresses different goals, e. g., searching for corresponding model sections for model integration in distributed modelling projects or evaluating process compliance, amongst others. Manual model analysis can be costly, as the number of models to be analysed may rank in the thousands [YDG10]. We therefore argue that a semi-automated model analysis approach being suitable for different modelling languages and for different application scenarios is highly beneficial. Such an approach has to consider two basic aspects: First, it should be able to recognize structures occurring within a model. Second, the approach should recognize the labels of the model elements. It is crucial that the model elements’ contents are unambiguous, thus the approach should incorporate a mechanism that relies on semantic standardization. In this contribution, we present a semi-automated model analysis approach, which makes use of semantic standardization to assure comparability as a precondition for model analysis and allows for flexible pattern specification and matching. Our research follows the design science paradigm outlined by [He04]. This integrated approach is based on our previous research on naming conventions [DHL09] and generic pattern matching [De10]. The remainder of this contribution proceeds as follows: In Section 2, we present a literature overview of existing model analysis approaches. Section 3 introduces the conceptual specification of the approach. Section 4 provides an application example. We close with an outlook to future research in Section 5. 201 2 Related Work Different analysis approaches proposed in the literature can be divided according to their primary goal into quality evaluation, exploration, and comparison approaches. Notable work concerned with evaluating the syntactical as well as semantic quality of conceptual models has, for example, been proposed by [Fr09], [LSM09], or [Go08]. In terms of model exploration, various analysis approaches have been proposed by [Az09] [Es09], or [TIR07]. To compare two or more models to one another, algorithms have been developed by [Di11], [YDG10], or [DDM08], amongst others. These approaches deal with particular analysis task and are therefore only suitable in their respective domains. We argue that it would be beneficial to have a generic analysis approach being suitable for any modelling language and in any application domain. The following section introduces such an approach. It is based on our previous work on enforcing naming conventions [DHL09] and identifying arbitrary structures in conceptual models [De10]. 3 Conceptual Specification The overall procedure of our analysis approach is subdivided into two main steps as depicted in Figure 1 (black-shaded elements are adapted from the pattern matching approach, grey-shaded elements are adapted from the semantic standardization approach, and non-shaded elements are new). First, the analysis is defined (cf. section Analysis Definition in Figure 1). Second, the analysis is applied to a set of models in order to generate a report as a result (cf. section Report Generation in Figure 1). An Analysis is composed of one or more Sub-analyses, each of them having a particular Search Criterion. The search criterion describes the properties of the expected analysis results (e.g., “find all receipt structures containing the term “invoice). Furthermore, it has to be defined whether the scope of an analysis is to explore a single set of models or to perform a comparison of two model sets (cf. attribute scope). To assure that all sub-analyses within an analysis can be applied to the same model base, an analysis can be composed only of those sub-analyses which have the same scope. Each sub-analysis is based on a Search Criterion specifying the fact to be searched for. Any search criterion consists of either a single Atomic Search Criterion or a Composed Search Criterion. Atomic search criteria are further specialized as: ! Pattern Equivalence Class (PEC) to search for different structural patterns regarded as equivalent (e.g., two different data structures being recognized as similar) ! Structural Pattern to search for a specific model structure (e.g., a pattern representing activities in process models that are related to an application system) ! Element Types (e.g., all “application systems”) ! Phrase Syntax to search for model elements whose labels follow a certain syntax (e.g., model elements whose labels follow the syntax <verb, imperative> <noun, singular> in order to name process activities) ! Word Class to search for all words of a certain type within model elements’ labels (e.g., all nouns to identify business process objects) 202 ! Word to search for a particular word within the label of model elements (e.g., the particular word “invoice” in order to identify all data models containing invoice data) ! Comparison Type to define a criterion for the comparison of two model sets. A comparison type can take the values “structural pattern”, “pattern equivalence class”, “element type”, “word class”, “word”, or “phrase syntax”. If an analysis has the scope “comparative”, a result found in the one model set is compared to all results found in the other model set. If both results are equivalent concerning the comparison type, they are returned as a result pair marked as “equivalent”. For example, finding similar structures in data models requires defining a pattern equivalence class containing these structures as structural patterns. Then, a comparative analysis can use this class as a search criterion. In addition, it uses the comparison type “pattern equivalence class” to relate every pattern match in the one model to every match in the other model, and possibly a further comparison type “word” to only return structure pairs containing the same term (e.g., “invoice”). Analysis Definition Criterion Restriction (0,n) Analysis (1,n) Analysis Composition (1,n) (0,n) Sub-analysis (1,1) SubanalysisCriterion (0,n) (0,n) Scope (0,1) Search Criterion Atomic Search Criterion D,T D,T Pattern Equivalence Class (0,n) Scope Criterion Structure (1,n) Composed Search Criterion Structural Pattern Output Type Operator Analysis Result Subanalysis Result (1,1) (1,1) Report (1,n) Report Composition (1,1) Report Element Comparison Match (0,n) (0,n) Report Element Fact (1,1) (1,2) Fact (1,1) Report Target (0,n) Model Set (0,n) (1,n) Model SetAssignment (0,n) Model (0,n) Model-FactAssignment D,T Element Type Structural Pattern Occurrence Phrase Syntax Element Occurrence Word Class Phrase Syntax Occurrence Word Word Occurrence Comparison Type Report Generation Figure 1. Conceptual Specification of the Analysis Approach As a comparison type defines only a criterion for the comparison of two model sets, this criteria is only available for comparative sub-analysis (i.e., the attribute scope is set to “comparative”). All the other atomic criteria can be used regardless of the specified scope. A search criterion that contains more than one atomic search criterion is defined as Composed Search Criterion. It is composed of further complex or atomic search criteria, which are connected through a logical operator. The search criteria to be combined are specified by the Criterion Structure. To define the logical operator to be used for the combination of these search criteria, we introduce the attribute Operator, which can hold 203 one of the values “AND”, “OR”, “XOR” or “NOT”. A Criterion Restriction is used to refine an atomic search criterion. Here, a search criterion – either an atomic or a complex one – serves as a constraint for an atomic search criterion restricting the resulting set of model fragments. Therefore, the restricting search criterion is directly assigned to the atomic search criterion to be restricted. Finally, an analyst has to specify the granularity of the analysis results to be displayed. Therefore, we introduce the attribute Output Type. For example, an analysis is defined to search for structural pattern occurrences. By defining patterns as output type, the pattern occurrences contained in the analysis’ result are included in the report. By setting the value to “element”, the report is straightened to visualize occurrences of single model elements, which are contained in the returned pattern occurrences. By defining “phrase syntax” as output type only phrase syntax occurrences contained in the returned pattern occurrences are visualized, and so on. To avoid empty reports, the output type has to be defined in respect to specified search criteria. The results of an analysis are visualized as a Report. Depending on the scope of an analysis, a report is targeted at either one Model Set for an explorative analysis or two model sets for a comparative analysis. Each model set consists of one or more Models to be analysed. A report is composed of one or more Report Elements, each of them resulting from one sub-analysis. A report element represents a single row in a report and shows the particular Facts returned as search results from the corresponding sub-analysis. A fact defines a particular match of the sub-analysis’ search criterion, which is shown in the report. In respect to the possible output types of a sub-analysis, a fact can be a Pattern Occurrence, an Element Occurrence, a Phrase Syntax Occurrence, or a Word Occurrence. For one particular sub-analysis of the aforementioned example, all process activities that are related with a specific application system are included in the report element as particular element occurrences. Facts resulting from a comparative analysis are linked to each other as Comparison Matches. This way, equivalent result pairs are defined by relating a fact occurrence in the one model set to the matching fact occurrence in the other one. 4 Application To demonstrate the feasibility of our model analysis approach, we developed a prototypical implementation combining both structural pattern search and linguistic standardization features. As an implementation basis, we used a meta-modelling tool which was available from a previous research project. Since our model analysis approach is generic in nature, it is applicable to a variety of business scenarios. To evaluate its general feasibility, however, we decided to provide an application example in an area where we believe the approach is most beneficial, namely in case of mergers and acquisitions. A major challenge in merging two or more companies is integrating the respective IT landscapes [MB07]. A first step toward IT integration in merger scenarios is identifying the different application systems that support a particular business activity in all involved companies. 204 To identify such structures, we define a simple analysis with the output type pattern. The report will show us all model structures that match the predefined search criteria. For the example of application systems supporting specific business activities we therefore defined a structural pattern called “Function->Application System” for EPCs. This pattern returns all functions that are directly related to an application system. As far as the linguistic features are concerned, we define the words “customer” and “CRM” to comprise the necessary vocabulary for this domain. Given this pattern and these terms we can construct the search criterion that allows for searching occurrences of the “Function>Application System” pattern. The search is further restricted to include only those pattern occurrences containing either the word “customer” or “CRM” at least once. Figure 2. Exemplary Analysis As a model basis, assume that we have two fictional companies. For each of these companies we modelled the three business processes “campaign execution”, “order processing”, and “request processing” as EPCs. Running the analysis as described above results in the report depicted in Figure 2. In this case, the business process “campaign execution” contains two occurrences of the specified search criterion. The processes “order processing” and “request processing” each contain three occurrences. Clicking on one model allows for navigating to it. Each fact is then highlighted, so the analyst can easily locate the different fact occurrences. In the example, all functions that are directly connected to an application system and contain the terms “customer” or “CRM” are highlighted. 5 Outlook The contribution of this paper is two-fold: on the one hand, it provides a convenient tool to practitioners and professionals that can be used in a multitude of application scenarios, regardless of what modelling languages they prefer. On the other hand, we provide an innovative approach to the model analysis body of knowledge. It takes into account both the intensively discussed requirements of semantic interoperability and structural pattern matching. It is applicable, reusable and thus evaluable in multiple scientific, educational and professional scenarios. In future research, we aim at developing an automated or at least semi-automated approach to integrate a number of conceptual models to one consolidated model. Furthermore, we intend to develop meaningful metrics for the analysed models. 205 References [Az09] Azevedo, L. G.; Santoro, F.; Baião, F.; Souza, J.; Revoredo, K.; Pereira, V.; Herlain, I.: A Method for Service Identification from Business Process Models in a SOA Approach. In (van der Aalst, W.M.P.; Mylopoulos, J.; Sadeh, N. M.; Shaw, M. J.; Szyperski, C.; Halpin, T. et al. Eds.): Enterprise, Business-Process and Information Systems Modeling, LNBIP, vol. 29. Springer, Heidelberg, 2009; pp. 99-112. [DDM08] van Dongen, B. F.; Dijkman, R.; Mendling, J.: Measuring similarity between business process models. In (Bellahsene, Z.; Léonard, M. Eds.): Proceedings of the 20th International Conference on Advanced Information Systems Engineering, Montpellier, 2008, pp. 450-464. [De10] Delfmann, P.; Herwig, S.; Lis, L.; Stein, A.; Tent, K.; Becker, J.: Pattern Specification and Matching in Conceptual Models. A Generic Approach Based on Set Operations. In: Enterprise Modelling and Information Systems Architecture 5 (2010) 3, pp. 24-43. [Di11] Dijkman, R.; Dumas, M.; van Dongen, B.; Käärik, R.; Mendling, J.: Similarity of business process models: Metrics and evaluation. In: Information Systems 36 (2011) 2; pp. 498-516. [DHL09] Delfmann, P.; Herwig, S.; Lis, L.: Unified Enterprise Knowledge Representation with Conceptual Models – Capturing Corporate Language in Naming Conventions. In: Proceeding of the 30th International Conference on Information Systems (ICIS 2009), Phoenix, 2009, pp. 13-26. [Es09] Esswein, W.; Weller, J.; Stark, J.; Juhrisch, M.: Identifikation von Services aus Geschäftsprozessmodellen durch automatisierte Modellanalyse. In (Hansen, H. R.; Karagiannis, D.; Fill, H.-G. Eds.): Proceedings der 9. Internationalen Tagung Wirtschaftsinformatik, Vienna, 2009; pp. 513-522. [Fr09] Friedrich, F.: Measuring semantic label quality using WordNet. In: Proceedings des 8. GI-Workshops Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (EPK). CEUR-WS.org, 2009; pp. 7-21. [Go08] Governatori, G.; Hoffmann, J.; Sadiq, S.; Weber, I.: Detecting Regulatory Compliance for Business Process Models through Semantic Annotations. In (van der Aalst, W.M.P.; Mylopoulos, J.; Sadeh, N. M. et al. Eds.): Business Process Management Workshops. Springer, Heidelberg, 2008; pp. 5-17. [He04] Hevner, A. R. et. al.: Design Science in Information Systems Research. MIS Quarterly 28, 2004; pp. 75-105. [LSM09] Leopold, H.; Smirnov, S.; Mendling, J.: On labeling quality in business process models. In: Proceedings des 8. GI-Workshop Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (EPK). CEUR-WS.org, 2009; pp. 42-57. [MB07] Mirklitz, T.; Buxmann, P.: IT Standardization and Integration in Mergers and Acquisitions. A Decision Model for the Selection of Application Systems. In: Proceedings of the 15th European Conference on Information Systems (ECIS 2007), St. Gallen, 2007, pp. 1041-1051. [TIR07] Thom, L. H.; Iochpe, C.; Reichert, M.: Workflow patterns for business process modeling. In: Proceedings of Workshops and Doctoral Consortium of the 19th International Conference on Advanced Information Systems Engineering (CAiSE 2007), Trondheim, 2007; pp. 349-358. [YDG10] Yan, Z.; Dijkman, R.; Grefen, P.: Fast business process similarity search with featurebased similarity estimation. In: Proc. of the 2010 international conference on the move to meaningful internet systems, Hersonissos, 2010; pp. 60-77. 206 System Architecture Validation with UML André Pflüger, Wolfgang Golubski Westsächsische Hochschule Zwickau Fachgruppe Informatik Dr.-Friedrichs-Ring 2A 08056 Zwickau {Andre.Pflueger|Golubski}@fh-zwickau.de Stefan Queins SOPHIST GmbH Vordere Cramergasse 13 90478 Nürnberg Stefan.Queins@sophist.de Abstract: The foundation of every system is the architecture. It has to be designed according to the corresponding system requirements by the system architect who is also responsible for ensuring that it fits to the system requirements even if these change due to new conditions during development process. Our approach defines a model driven process for the architect to validate system architecture against system requirements based on UML. It supports the architect in designing the architecture and in analysing the impacts of requirements changes. 1. Motivation Designing and validating system architectures are time- and work-consuming tasks. The responsible person for those tasks, the system architect, must have special expertise in this area to create the basic foundation of the system, experience and social skills are also appreciated. The number of requirements is growing with the systems complexity which also increases the number of dependencies between them. The system architect does not only have to look at all these requirements, he also has to handle requirements changes and their impacts on the system architecture. Due to customer’s desire for high flexibility, requirement changes are no longer limited to analysis phase and early design phase. They occur up to the end of implementation phase making architect’s work a big challenge. A common proceeding can be described as follows: The architect creates an architecture draft and improves it iteratively. The validation is done manually by stepping through the architecture-relevant requirements. There is no defined validation process which might cause unintentional omitting of important aspects. The validation is based on estimations due to the architect’s experiences and only in special cases, mostly for critical requirements, it is based on verifiable results. According to the required work effort documentation and validation are only done completely for important, e.g. review appointments. We think that the process described is not sufficient for developing complex systems because there is no defined validation process to achieve repeatable results. Figure 1 shows the four levels of our approach to support the architect in his work. The top-level defines our model-based validation process which is independent from any specific modelling language. According to apply this process we choose the Unified modelling Language (UML) and develop UML-specific support tool approaches in levels two and three. The implementation of these tool approaches are part of the fourth level. The validation process is used in conjunction with the iterative design of the system architecture which can be partly automated. So-called validation targets sum up architecture-relevant requirements on an abstract level suitable for architecture design. 207 Figure 1: different levels of the approach This level gives the architect a better view on the system architecture according to the architecture-relevant requirements and makes complex correlations visible. For every validation target the architect creates a process to check if the associated requirements are fulfilled by the system architecture. The architecture is valid if all validation targets are valid. Requirements can be associated to more than one validation target supporting the architect during impact analysis after requirement changes. This approach depends on a model-based system documentation used as data source for the validation target processes and for a seamless documentation of system architecture design. For every validation target the architect may create a specific notation allowing him to model all necessary information for the validation target process. Based on the choice of UML information not available is added by using the UML profile mechanism [UML10]. In section 2 we will discuss related work to our approach. Section 3 describes the validation process in detail and section 4 deals with the validation target specific notations using the UML profile mechanism and the separating of development and validation model. In section 5 we apply the introduced approach to an example from the area of embedded systems. Section 6 lists up benefits and our experiences before section 7 concludes the paper and overviews future work. 2. Related Work According to our research there are no approaches defining a model driven process for the architect to validate system architectures against requirements which includes the support for the architect for designing the architecture and analysing the impacts of requirement changes. The project System Architecture Virtual Integration (SAVI) [FEI10] initiated by the Aerospace Vehicle Systems Institutes is based on three key concepts: a reference model, a model repository with model bus and a model based development process. Models using i.e. UML, AADL or SysML and mapped to the reference model can be compared with the content of a requirements repository. In theory a validation of system architectures against requirements would be possible but the overhead would be high because this is not the projects intention. Furthermore, the project only exists in the description of a feasibility study. There are modelling-language-specifications available for special topics like the System Modelling Language (SysML) [OMG10a], the Architecture Analysis and Design Language (AADL) [CMU11] or the Modelling and Analysis of Real-Time and Embedded Systems (MARTE) profile [OMG10b] which could be used but they are limited to a specific domain and they cannot be extended to add validation specific data. 208 The tool PREEvision of aquintos [Aqu11] supports a model based development and evaluation of electric and electronic architectures. The modelling language is based on a graphical notation using an own domain specific meta-model, architecture relevant information are provided by a data model. Our approach is focused on the whole system architecture including software components and uses an extension of the domain specific notation by using the profile mechanism of the UML. 3. Validation process The first step towards a model driven validation of system architectures is defining a process for the architect. This process should be independent from any special system or modeling language. It describes the necessary steps initially building up the validation and how to react on requirement changes. First the validation targets are detected from the requirements, especially non-functional requirements. The architect creates a validation process for every validation target and a validation target specific notation based upon the domain notation to add validation specific information to the validation model. By running all validation processes, manual or automatic, the architecture is validated. In failure case the architecture has to be adjusted and revalidated. These modifications are transformed into development model in case of a successful validation. The validation process restarts after requirements change. [Pfl10] describes this process in detail. 4. Modeling language UML According to the four levels presented in figure 1 our approach does not depend on any particular modeling language but for practical usage a choice is necessary. We decided for the UML because it is a widespread and accepted standard in research and industry. It provides two possibilities to extend its meta-model: meta-model extension and the profile mechanism [UML10]. By creating and using a profile composed of stereotypes, tagged values and constraints for every validation target the architect can add the relevant information to UML elements without much effort. An UML element can own several stereotypes from different profiles, i.e. from different validation targets, thus there is no need for modeling dependencies between different validation targets just because they add information to the same UML element easing profile reuse. The UML like other meta-model based languages supports the exchange of data between different models. For this purpose the specification defines the XML Metadata Interchange (XMI) format. We use the Eclipse Modeling Framework (EMF) [EMF10] for implementing tools supporting the system architect in creating the validation model by transferring selected UML elements from development model to validation model and in synchronizing the two models after system architecture modifications. More details about this topic can be found in [Pfl10]. 5. Radar system example A radar system receives echoes of electro-magnetic signals from an antenna, processes these data closed to real-time and provides tracks which are the desired objects the radar engineer wants to see on his radar display. The data processing in a radar system is almost sequential. It is just separated by data processing variants due to different types of signals which are in our example: sea targets, air targets and near range targets. 209 These signals are characterized by different electro-magnetic wave forms and processing algorithms allowing the radar engineer to detect objects in a short or far away distance with different resolutions. The system processes a continuous stream of data so that the computing performance for data of a specific point in time is influenced by processing of past and future signals. For this example we consider the following requirement: - The system shall provide tracks for fed in test data after 320ms. (A1) - The system shall provide plots for fed in test data after 280ms. (A2) - The system shall be able to compute 3500 MBit/s data received from antenna. (A3) - The system shall consume less than 220Watt/h. (A4) - The temperature of each FPGA shall be less than 50°C. (A5) - The temperature of each microprocessor shall be less than 70°C. (A6) The system architecture describes software and hardware components, their connections and behaviour. For this example we focus on the components and their connections. Each software component has to have a dependency connection with stereotype executedOn to a hardware component indicating that it is executed on it. There are three hardware boards with two processing units, one microprocessor and one field programmable gate array (FPGA), each. According to the validation process the architect detects validation targets from system requirements in the first step. A1 and A2 are assigned to validation-specific aspect processing time (VT1), A3 to communication infrastructure (VT2), A4 to energy consumption (VT3) and A5 and A6 to system temperature (VT4). For the validation target specific notations the stereotype software has the tagged value mflops specifying needed floating point operations for the software component and the stereotype hardware has the tagged value performance providing the performance of processing units in MFlop/s. If we assume linear energy consumption and linear temperature rising for processing units in combination with a basic value, these data can be calculated by using processing unit load deduced by VT1’s examination process. We add the tagged values energyConsumption and basicEnergyConsumption to the stereotype hardware as validation target specific notation for VT3 and temperature and basicTemperature for VT4 (see figure 3). We add the stereotype communication with tagged value bandWidth to the association representing physical link between the board and the hardware component executing the first software component in the processing chain. After determine the validation targets, their corresponding examination processes and notations the architect creates the validation model illustrated in figure 2. Figure 2: Validation model for radar system validation 210 Figure 3: Validation target specific notations for VT1, VT2, VT3 and VT4 Table 1: result examination process VT1 Data Processing time [ms] tracks 313 plots 277 Table 2: result examination process VT2 Communication device Antenna – radar system Band width [MBit/s] 5200 Table 3: result examination process VT3 and VT4 Processing unit B1_FPGA Processor load [%] Temperature [°C] 26 48 35 B1_PowerPC 13 63 42 B2_FPGA 24 47 34 B2_PowerPC 8 60 37 B3_FPGA 14 43 28 B3_PowerPC 12 63 Total energy consumption Table 4: result examination process VT1 Data Processing time [ms] tracks 306 plots 270 Table 5: result examination process VT2 Communication device Antenna – radar system Band width [MBit/s] 5200 Energy [Watt/h] 41 218 Table 6: result examination process VT3 and VT4 Processing unit B1_FPGA Processor load [%] Temperature [°C] Energy [Watt/h] 25 47 34 B1_PowerPC 12 63 40 B2_FPGA 15 44 29 B2_PowerPC 28 74 55 B3_FPGA 13 43 27 B3_PowerPC 11 62 Total energy consumption 39 221 It contains validation specific information only and it is used as data source for automated validation. Some information of the development model has been transferred, some is not required and therefore has not been transferred and other has been added by the introduced profiles. The results of the system architecture validation, i.e. of the four validation targets, are shown in table 1 to 3.The system architecture passes the validation and therefore fulfils the regarded system requirements. There has been no architecture modification in the validation model so that synchronization of the models is not necessary. During development requirements are changing. In our example the customer changes requirement A1: Tracks shall be provided after 310ms instead of 320ms. 211 The revalidation after requirement change fails because VT1 cannot be validated: 313ms is greater than 310ms. The architect has to change the system architecture. He assigns software component sweep processing to the PowerPC of Board_2. This modification is memorized because it has to be transferred to the development model in case of a successful validation. Although VT1 is valid after modification, the whole validation fails due to energy consumption (see table 4 to 6). By analyzing validation results including former ones the architect is able to identify the problem. The processing unit load of the PowerPC on Board_2 has been raised causing raising energy consumption which cannot be compensated by falling energy consumption of FPGA on Board_2. The architect restores the former architecture, exchanges the software components burst processing and near range target processing and reruns architecture validation. These modifications are transferred to development model because validations for all validation targets are successful. 6. Conclusion and future work System development has to deal with evolving conditions challenging the system architect who has to design and document the architecture just as validate it against system requirements considering influencing parameter. The introduced approach defines a model-based validation process integrated into iterative development of system architectures. The process can be partly automated reducing time and effort for validation. The approach supports the architect in keeping track of architecture specific aspects and their dependencies such as analysing impacts after requirement changes. The approach has been developed with the help of projects of the SOPHIST GmbH and our experiences from system developments. Our experience shows that extra work caused by this validation process amortizes within several iterations of architecture design and requirement changes. Currently we are developing tools to support the architect in model-to-model transformation and using non-UML data sources during transfer process. In combination with the validation target management tool we try to provide a tool chain for the whole validation process increasing the usability. We also develop a validation target process simulation to gain experience with heavily dependent validation targets. References [Aqu11] PREEvision by aquintos, http://www.aquintos.com, last access on 2011-02-04 [CMU11] Architecture Analysis & Design Language (AADL), Carnegie Mellon University, http://www.aadl.info, last access on 2011-01-03 [EMF10] Eclipse Modeling Framework (EMF), Eclipse Foundation, http://www.eclipse.org/emf/, last access on 2010-11-28 [Fei10] P. Feiler, L. Wrage, J. Hansson, System Architecture Virtual Integration: A Case Study, Embedded Real-time Software and Systems Conference, May 2010 [OMG10a] System Modeling Language (SysML), Object Management Group, http://www.omgsysml.org/, last access on 2010-11-28 [OMG10b] UML-Profil MARTE, http://www.omgwiki.org/marte/, Object Management Group, last access on 2010-11-28 [Pfl10] Pflüger A., Golubski W., Queins S.: Validation Of System Architectures Against Requirements, International Joint Conferences on Computer, Information and System Sciences, Engineering (CISSE’2010), published by Springer in Summer 2011 [UML10] Unified Modeling Language (UML) Version 2.3, http://www.uml.org, 2010 212 Tool Support for the Comprehensive Modeling of Quality Information within Business Process Models Robert Heinrich, Alexander Kappe, Barbara Paech Institute of Computer Science, University of Heidelberg Im Neuenheimer Feld 326, 69120 Heidelberg, Germany {heinrich, paech}@informatik.uni-heidelberg.de kappe@stud.uni-heidelberg.de Abstract: Business process modeling is commonly used to document information about structure and behavior of a business process. However, current business process modeling notations do not support well the expression of quality information relating to business processes. Organizations are interested in the capturing of quality information for quality improvement of business processes and supporting IT systems. We are developing an approach to capture quality information comprehensively within business process models. In contrast to existing approaches, our notation allows the capturing of a broad range of quality characteristics as well as detailed attributes and measures. The approach is implemented as an extension of a CASE tool. Moreover, we discuss lessons learned from the application of the approach to a business process from practice. 1 Introduction Business process modeling is widely used within organizations as a method to increase awareness and knowledge of business processes, and to deconstruct organizational complexity [BGR05]. Current business process modeling notations do not aim at expressing quality information (QI) such as information about maturity or security of a business process (cf. [Ko08], [PZ08], [SZS10]). Hence, quality requirements are often not considered at the process modeling stage, which results in increased costs and delays in the further development of business processes and involved IT systems. Annotating the process model with QI contributes to a model that provides a more complete representation of the overall business process [PZ08]. A (graphical) expression of QI together with information on structure and behavior within a single model would increase the modeler’s focus on quality at the process modeling stage. Therefore, as stated in related work (cf. [SZS10], [PZ08]), it facilitates the capturing of quality requirements and results in a more complete set of requirements. Although the benefit of QI captured in a process model for early requirements elicitation has already been identified by other authors, current approaches only focus on single QI [HKP11]. Our research aims at capturing a comprehensive set of business and IT quality requirements 213 and the coordination of these requirements. A first step in this direction is the comprehensive modeling of QI within business process models, as business process models are a starting point of requirements elicitation [Ko08]. In contrast to software product quality, which for example is standardized in the ISO/IEC 9126 quality model [ISO01], there is no common quality standard for business processes. Therefore, we developed a comprehensive quality model for business processes that is based on software product quality standards [HP10a], [HP10b]. In this paper, we describe an approach to present the QI of our quality model within a business process model and provide prototypical tool support of our approach. The paper is structured as follows: In Section 2, as a background, we sketch our quality model. Section 3 describes our approach to model QI and the prototypical tool support. In Section 4 we present lessons learned from an exemplary application of the approach and tool. Section 5 concludes the paper and presents future work. 2 Background In the quality initiative domain process quality is in the focus of research and practice for some decades and there are many high-level and expert-based techniques like TQM, Kaizen or Six Sigma. However, a comprehensive view on the – in particular nonfinancial – quality aspects of a business processes is still missing. Therefore, we developed the comprehensive Business Process Quality Reference-Model (BPQRM) [HP10a], [HP10b] using characteristics we transferred from software product quality standards. To the characteristics we allocated a broad range of detailed quality aspects from business process management literature. We use a hierarchical structure of QI defined as follows. A business process quality characteristic is a category of business process quality attributes, for example the maturity of an activity. A business process quality attribute is an inherent property of a business process that can be distinguished quantitatively or qualitatively, for example the error density of an activity. A business process quality measure is a variable to which a value is assigned as the result of measurement. Measures can be defined as base measures or derived measures. A base measure is a measurement for which the value is directly applicable to the process, e.g. the number of errors or the number of (sub) activities. A derived measure is a measure that is defined as a function of two or more values of base measures, e.g. the number of errors per activity size. In the following, we use the term QI as a superset of characteristics, attributes and measures. Business process quality refers to the components of a business process. Components are the activities of the process, the actors performing these activities, the objects handled and created by the process as well as the resources necessary for its execution. As an activity can be subdivided into sub activities, we consider a process itself as an activity. In the BPQRM we associated a set of quality characteristics adapted from software product quality standards to each component of a business process. Figure 1 shows the BPQRM. The nodes correspond to the components and the characteristics are listed 214 either within a node or on an edge between nodes. See [HP10b] for further information. Fig. 1: Business Process Quality Reference-Model 3 Approach and Tool Support We conducted an extensive literature and tool survey [HKP11] on research approaches and tools from practice for modeling QI within business process models. As shown in the survey, neither of them was able to express QI covered by more than 9 characteristics of the BPQRM. Moreover, in most cases the surveyed tools were not able to express QI in the process modeling view. The deficiencies identified in the survey motivated us to develop an approach to model QI comprehensively within business process models and to provide a new tool support. The research question thereby is how to enable the modeling of a large set of different QI without a major increase of complexity of the modeling notation. We decided to add small graphical symbols to already existing model elements. To each characteristic in the BPQRM we associate a graphical symbol. A detailed allocation of the symbols to the characteristics can be found in [Ka11]. To each symbol we associate attributes, derived measures, base measures and the related values in tabular form. The approach is implemented prototypically as an extension of the Eclipse-based CASE tool UNICASE (http://unicase.org/). 215 Figure 2 shows a screenshot of our tool. The process model is presented in a split screen view together with the corresponding tables of attributes and measures. Therefore, – in contrast to the surveyed tools – information on structure and behavior as well as information on quality can be presented in a single view. In the process modeling view (Business Process Model) the modeler can capture information on structure and behavior of the business process as a BPMN [OMG11] model and can additionally capture the quality characteristics of the BPQRM. The modeler can add quality characteristics to a process model element by dragging and dropping the characteristic icons from the toolbar beside the process model to the corresponding process model element. By clicking a characteristic icon in the process model, the table of attributes and measures related to the selected characteristic appears in the QI Details view below. Here the modeler can capture the attributes, measures and their values. Thus, it is possible to model a large set of different QI (in the form of characteristics) as well as to capture detailed QI (in the form of attributes and measures) without a major increase of complexity of the process model. Fig. 2: Screenshot of the Process Modeling Editor Note that in our view it is important to model QI simultaneously with information on structure and behavior because QI is often elicited together with information on structure and behavior. We think it is not sufficient to enter QI ex post into the model as QI may influence the structure and behavior of a business process. Our approach is applicable to an arbitrary graphical modeling notation. We utilize the BPMN as an example as it is an 216 up-to-date and wide-spread modeling notation for business processes. Moreover, the BPMN is well suited to be extended. 4 Exemplary Application In the previous section, we described our approach and the prototypical tool support. In the following, we discuss lessons learned by the application of the tool in a first evaluation. We wanted to get first feedback whether our approach is an adequate means to model the QI of a business process from practice. As an example we choose the process of writing discharge letters in a hospital, because all the components of the BPQRM are contained in the process and there is a large number of QI to be captured. A discharge letter is a summary of the performed patient treatment and is used for the communication between physicians for follow-up treatments. The modeled process consists of 15 activities and handles 5 information objects. 4 actors and 1 IT system are involved in the process. Altogether, we captured 12 different characteristics of the BPQRM and related attributes and measures. For activities we captured the characteristics maturity, time behavior, interoperability, attractiveness and resource utilization. For resources we captured the characteristics maturity, attractiveness and learnability and for information objects we captured currentness, compliance, availability and operability. We did not capture QI related to actors as this QI was excluded on request of the hospital. In Figure 2, as an example, a part of the process is modeled in the process modeling editor. The diagram shows 4 activities and 2 data objects annotated with characteristic icons which are relevant in the process. Further information on the exemplary application can be found in [Ka11]. Next, we discuss lessons learned by applying our approach in practice. The example showed that our approach is a valid and practically applicable means to model the 12 different characteristics that are relevant in the process. In general, annotating a large set of characteristics to a single model element (the worst case is 26 characteristics per model element for the process components activity and resource) very likely will reduce the clarity of a model developed using our approach. It turned out, however, that in the example the number of modeled characteristics per model element was much lower (typically 1 to 5 characteristics per model element) because not all of the characteristics were relevant to every model element in the specific process. In the process model we only visualize the quality characteristics. One characteristic icon can represent several attributes and measures. The limitation to characteristics is a useful means to allow a compact overview of the QI. However, the modeler cannot access a specific attribute or measure directly. Instead s/he has to click on the corresponding characteristic icon. For example, if the modeler wants to view the value of the measure number of errors, s/he first has to click on the maturity icon (see Figure 2). In the future the tool support may provide functionality for the direct retrieval of a specific attribute or measure, e.g. by searching for its name. The split screen view is a useful means to show details of a single characteristic together with the process model element the characteristic is annotated to. Moreover, the tool 217 allows the switching between characteristics quickly. However, selecting single characteristic icons may be cumbersome, if the modeler wants to view QI aggregated over different characteristics or model elements. Future work on the tool is required. 5 Conclusion and Future Work In this paper, we presented an approach to model QI comprehensively within a business process model and provide prototypical tool support as an extension of the Eclipse-based CASE tool UNICASE. The approach puts quality in the focus of business process modelers and therefore helps to capture relevant QI early at the modeling stage. It is built on the results of an extensive literature and tool survey. To the best of our knowledge this approach is the first one which allows the modeling of a comprehensive set of QI within a business process model and provides guidance on the QI to be modeled. As a next step we plan to conduct further evaluations of the approach. We want to compare our approach to goal-oriented approaches that model quality requirements separately in a goal hierarchy and link them to processes. Moreover, the usability of the prototypical tool support has to be revised. Extending the tool support by additional functionality for automatic QI calculation, analysis or simulation is also desirable. References [BGR05] Bandara, W., Gable, G.G., Rosemann, M.: Factors and measures of business process modelling: Model building through a multiple case study, European Journal of Information Systems Vol. 14 No. 4, pp. 347-360 (2005) [HP10a] Heinrich, R., Paech, B.: Defining the Quality of Business Processes, In: Engels, G., Karagiannis, D., Mayr, H.C., eds.: Modellierung 2010, Lecture Notes in Informatics Vol. P-161, GI, pp. 133-148 (2010) [HP10b] Heinrich, R., Paech, B.: Business Process Quality - A Technical Report, Technical Report, Software Engineering Heidelberg (2010) [HKP11] Heinrich, R., Kappe, A., Paech, B.: Modeling Quality Information within Business Process Models, In: Proceedings of the 4th SQMB Workshop, TUM-I1104, pp. 4-13 (2011) [ISO01] ISO/IEC 9126-1: Software engineering — Product quality — Part 1: Quality model, First edition (2001) [Ka11] Kappe, A.: Entwicklung und Umsetzung eines Konzepts zur Modellierung von Qualitätsinformationen in einem Geschäftsprozessmodell, Master Thesis, Software Engineering Heidelberg (2011) (in German) [Ko08] Korherr, B.: Business Process Modelling: Languages, Goals, and Variabilities, VDM Verlag, Saarbrücken, Germany (2008) [OMG11] OMG: Business Process Model and Notation (BPMN), Version 2.0, Object Management Group (2011) [PZ08] Pavlovski, C.J., Zou, J.: Non-functional requirements in business process modeling, In: Proceedings of the 5th Asia-Pacific conference on Approachual Modelling, (APCCM 2008), CRPIT, 79. Hinze, A., Kirchberg, M. (eds.) ACS, pp. 103-112 (2008) [SZS10] Saeedi, K., Zhao, L., Sampaio, P.R.F.: Extending BPMN for Supporting CustomerFacing Service Quality Requirements, In: Web Services, IEEE International Conference on, IEEE Computer Society, pp. 616-623 (2010) 218 Understanding IT-Management and IT-Consulting Teaching as Product-Service System: Application of an Engineering Model Matthias Boehm, Carl Stolze, Oliver Thomas University of Osnabrück Information Management and Information Systems Katharinenstraße 3 49074 Osnabrück { matthias.boehm | carl.stolze | oliver.thomas }@uni-osnabrueck.de Abstract: In this research-in-progress paper we conceptualize the teaching of IT-Management and IT-Consulting as a hybrid package of products (resources) and services (teaching). This understanding offers a new perspective on teaching approaches and creates new opportunities for all stakeholders. Following a wellestablished procedure model for product-service systems (PSS) engineering, we derive the customer requirements to the hybrid package. Than a product model is developed. Based on these findings, an Education Integration Platform Solution (EIPS) is prototypically designed. Finally, a conclusion and outlook are given. 1 Introduction – The Challenge of Teaching ITMC The current business and information technology (IT) environment can be characterized by dynamically evolving concepts and technologies as well as unprecedented volatility [OB11]. This fact poses challenges on the future working force, which can only be faced by permanent training of skills and knowledge [La10]. A combination of several crossdisciplinary qualifications is necessary for managing the complexity of the environment [Wi02]. However, not only the professionals have to cope with new technology and structures, also educational systems face challenges, like for example technological and organizational change, globalization and international commerce as well as environmental challenges [OB11]. It has been shown for example that sustainability concerns have an impact on teaching approaches [SBZ11]. Furthermore, what people learn, how they learn, and where they learn will radically change in future [Wa07]. IT management and IT consulting (ITMC) are two important fields, which both are very personal-intensive [CM09]. IT management covers different areas like managing IT resources (and personnel) as a competitive advantage or the development and operation of information systems [Lu04, CM09]. In this field, a variety of IT professionals, like programmers, analysts, IS managers and others, are employed. In the following, we focus on analysts and IS managers. IT consultants focus on building, managing and 219 operating information systems [VSB12]. They work as intermediaries between IT and business function [BD95]. Teaching ITMC involves several substitutable products and services [BSB11]. One cannot solely focus on the actual act of teaching (service) [MT03]. The learning resources, in terms of presentations, working sheets, exercises and other documentation [TR05] are the physical part of the teaching product-service system (PSS). The special thing about understanding teaching ITMC as a PSS is the fact that the physical resources play a more important role than in other teaching cases. Participants often cannot attend every presence lecture due to frequent travelling in their jobs (this is especially true for IT consultants) and therefore a good documentation is required. Mobile and individual e-learning opportunities can support their learning. Furthermore, the ITMC field is wide and the content, which has to be taught, is complex and difficult to understand. Therefore, personal teaching and coaching components are highly relevant. Hence, the provision of this hybrid PSS has to be made transparent and measureable to all involved stakeholders. That is the reason why our central research question can be formulated as follows: How can PSS engineering methods be used to develop an integrated solution that allows and effective and efficient teaching of ITMC? 2 Towards an Integrated Solution 2.1 Method As we develop a holistic product-service system that incorporates the necessary aspects of teaching ITMC as well as satisfying the requirements of all stakeholders, we focus especially on the integrated design of products and services [TWL08]. Therefore, we use a method for PSS engineering, developed by [WSB04] that has been successfully applied in research [BFS11]. Following [BFS11], the procedure consists of three phases: (1) definition, (2) synthesis, and (3) analysis. First, the requirements of the PSS are derived and based on the to-be properties have to be defined. By separating the inquiry of the requirements from the definition of properties of the product-service system, the transformation of them into the properties of the PSS can be made transparent [TWL08]. In the second phase, new or changed characteristics and components of the hybrid service bundle with its inner relationships and dependencies are derived. Finally, the as-is properties of the service bundle are evaluated by comparison with the to-be properties. Here one has to clarify which requirements already have been fulfilled and which still have to be covered. 2.2 Requirements In order to determine the requirements to the PSS, we conducted qualitative expert interviews with six practitioners from international consulting companies and representatives of five universities during a workshop in February 2010 [BSB11]. As the findings of these interviews provide only a rough overview on the requirements, a deeper analysis is 220 necessary. Therefore, we conducted a literature review [WW02]. Search terms like teaching, training, information technology, IT management, IT consulting, Learning Management System or education system were used to search for relevant papers in leading journals (top 20 journals according to AIS) and conferences (ICIS, ECIS, WI, AMCIS, HICCS) within the last 20 years. These findings have been integrated into those from the expert interviews. The result is depicted in Table 1. Social and personcentric requirements ! Diffusion and transfer of knowledge between the stakeholders ! Giving opportunities for developing interpersonal skills ! Acquisition of needed technical skills and competencies Economic requirements ! Providing certificates after completion of program (value for money) ! Monetary or time savings and/or noticeable quality improvements ! Ensuring efficiency of the methods by measuring economic and ecological values Ecological requirements ! Minimizing the ecological impact of the program through state-of-the-art learning methods (e-learning, blended learning, simulation) ! Creating awareness among the stakeholders for ecological issues Execution-related requirements ! Integrated platform for all phases from enrollment over execution till evaluation and evolution (4E of Teaching) ! Rapid adoption of teaching new technologies and concepts ! Ensuring mobile as well as offline e-learning access ! Safeguarding and motivation for long-term impact and top management awareness and acknowledgement Table 1: Customer Requirements on the Teaching PSS. 3 Conceptualization and Implementation 3.1 Definition of To-Be Properties and Synthesis of Properties The to-be properties now can be defined based on the requirements. The collected data of the previous step (cf. Table 1) is grouped into functional aspects and subsequently transferred to the level of properties of the product model of the PSS. In Figure 1 an excerpt of the developed model is shown. The characteristics and properties as well as their relations are depicted. Within the synthesis phase, the to-be properties of the PSS are realized by the definition of system characteristics. Existing logical relations and interdependencies between product and service components within the PSS are illustrated by the inner relationships between characteristics (cf. Figure 1). Based on the customer requirements new characteristics of the PSS are added in order to analyze their impact on the previously determined requirements in the form of relations. As a result teaching ITMC is especially related to content, cooperation and mutual exchange together with the enabling technological platform. Hence, we focus on these aspects in a way that the characteristics of the software component of the PSS are constituted and their relations to the level of properties are determined (cf. Figure 1). 221 Inner Relationships Level of Characteristics Teaching ITMC Relations Stakeholder Participant Researcher Practitioner Level of Properties 4Es of Teaching Enrollment Execution Evaluation Evolution Content and Knowledge Adoption new Technologies Overcoming academia-practice gap Social Aspects Changed Behaviour Application of Skills Motivation Top Management Acknowledgement Certification Monitoring Costs Economic goals Ecological goals Resources Presentation Slides Worksheets and Exercises Documentation Teaching Module Training Unit Content Method Skill Competence Integration Software interfaces Data storage Document management Processes EIPS Data storage Integrated DWH Solution Reporting Maintenance Usability Intuitive operation Data quality Timeliness Granularity Scalability Adaption to growth of company Infrastructure Mgmt. Figure 1: Excerpt of the Level of Characteristics and Level of Properties of the Product Model. 3.2 Analysis of As-Is Properties By analyzing the as-is properties one can monitor the fulfillment of the design goals from various perspectives. For doing so, we use a descriptive and argumentative evaluation [Fr06]. We developed the PSS using expert interviews and a systematic literature review. The resulting product model fulfills the requirements, which have been gained by the definition and synthesis phase (cf. section 3.1). During the analysis we recognized that a data warehouse (DWH) needs to be integrated into the IT architecture [BK10] in order to cope with requirements like quality of data, the degree of integration as well as the generation of reports (cf. Figure 1). This DWH is incorporated into an Education Integration Platform Solution (EIPS) and additionally offers central services like a role concept and an authorization mechanism. Unlike existing Learning Management Systems, which have been mainly developed by looking at technical possibilities [ZZZ04], our system uses a holistic approach in looking at the user requirements on the complete ITMC teaching process as a whole. A high-level data model of the prototype is depicted in Figure 2 as Entity-Relationship Diagram. Of course, the stakeholders and their affiliation, e.g. university or company name, are represented. Stakeholders in EIPS can be participants, researchers and practitioners while feedback can be given to from any stakeholder to any other one. Researchers and practitioners work together in a partnership and therefore act as a tutor within a training unit. This training unit has several participants and consists of a hierarchy of training units which together form the module list. The necessary modules for teaching ITMC have been outlined by [BSB11]. Each training unit has its at least one associated content, but each content should only be covered by one training unit in order to avoid redundancies. The content is linked to a set of skills. Skills are ability to apply the learned content and competencies are defined as the proven ability to apply content 222 [EE11]. These two concepts are modeled separately in EIPS in order to document the learning progress. For each skill there are several teaching methods [HMT05] represented in the system. New teaching methods like simulation [LPP11] and practical case study exercises [TR05] are also supported by EIPS. Additionally, specific resources can be stored and assigned to one or more of the methods. M-R Feedback (0,m) Stakeholder Module (0,1) (0,m) Participant Participation in relevant units (0,n) (1,n) (0,1) Training Unit Method Lecture (0,n) C-T (1,n) Researcher Resource (0,n) (0,m) (1,n) (0,n) Literature Study M-S (1,n) (1,n) (0,n) (0,n) Partnership Affiliation Practitioner (1,1) Tutoring Service (1,n) Content (0,n) (0,n) ... Skill (0,n) (0,n) S-Cont S-Comp Competence Figure 2: Data Model of the EIPS. 4 Conclusion and Outlook We conceptualized teaching ITMC as a hybrid package of products (resources) and services (teaching) in this paper. Synthesis-analysis cycles of a systematic procedure model have been than run through in order to derive and implement of our integration concept. As our research is currently in progress, only the Education Integration Platform Solution (EIPS) has been briefly presented. The proposed approach offers some limitations and therefore raises further questions: First, we have not been able to evaluate the PSS entirely. This is the task of future research. Also a detailed comparison with other Learning Management Systems is required and needs to be done in a real world environment. Second, our approach cannot cover all requirements on an integrated approach. The success of teaching strongly depends on the persons who teach and those who are willing to learn (social aspects like mutual acceptance and understanding, motivation etc.). Future research might cover these issues in investigating mechanisms for facilitating them. The task of future research is to find out, how the proposed approach can be implemented and offered in an efficient way. However, we are convinced that the utilization of the PSS engineering method in the context of teaching is a novel approach which results in an effective solution. 5 Acknowledgements This paper was written in the context of the research project IMUCON which is funded by the European Regional Development Fund (ERDF). The authors acknowledge the support by ERDF and all involved project partners as well as the anonymous reviewers. 223 6 References BD95 BFS11 BK10 BSB11 CM09 EE11 Fr06 HMT05 La10 LPP11 Lu04 MT03 OB11 SBZ11 TR05 TWL08 VSB12 Wa07 Wi02 WSB04 WW02 ZZZ04 Bloomfield, B. P.; Danieli, A.: The Role of Management Consultants in the Development of Information Technology. The Indissoluble Nature of Socio-Political and Technical Skills. In Journal of Management Studies, 1995, 32; pp. 23–46. Boehm, M. et al.: Towards an Integrated Approach for Resource-Efficiency in Server Rooms and Data Centers: ECIS 2011 Proceedings, 2011; Paper 100. Baars, H.; Kemper, H.-G.: Business Intelligence in the Cloud? In PACIS 2010 Proceedings, 2010; Paper 145. Boehm, M. et al.: An Integrated Approach for Teaching Professionals IT Management and IT Consulting: AMCIS 2011 Proceedings, 2011; Paper 72. Cragg, P.; Mills, A.: Understanding IT Management in SMEs. In Proceedings of the European Conference on Information Management & Evaluation, 2009; pp. 116–123. European Parliament; European Council: The European Qualifications Framework (EQF) for Livelong Learning. http://ec.europa.eu/education/lifelong-learningpolicy/doc44_en.htm, accessed 20 May 2011. Frank, U.: Towards a Pluralistic Conception of Research Methods in Information Systems Research. ICB Research Report No. 7, University Duisburg-Essen, 2006. Heim, G. R. et al.: Experiential Learning in a Management Information Systems Course: Simulating IT Consulting and CRM System Procurement. In Communications of the ACM, 2005, 15; Article 25. LaFrance, G.: Bridging the IT Skills Gap Through Industry and Academic Collaboration. In Employment Relations Today, 2010, 36; pp. 25–30. Léger et al.: Business Simulation Training in Information Technology Education: Guidelines for New Approaches in IT Training. In Journal of Information Technology Education, 2011, 10; pp. 39–53. Luftman, J. N.: Managing the Information Technology Resource. Leadership in the information age. Prentice Hall, Upper Saddle River, N. J, 2004. Minch, R. P.; Tabor, S. W.: Networking Education for the New Economy. In Journal of Information Technology Education, 2003, 2; pp. 51–59. Osorio, J.; Bulchand, J.: Moving towards 2020: A Tentative Approach to ITEM. In (Tatnall, A.; Kereteletswe, O.; Visscher, A. Eds.): Information Technology and Managing Quality Education. Springer Boston, 2011; pp. 104–112. Stolze, C. et al.: Towards Sustainable IT by Teaching Governance Practices for InterOrganizational Dependencies: Proceedings of IFIP 8.6 Hamburg Conference, 2011. Tatnall, A.; Reyes, G.: Teaching IT Project Management to Postgraduate Business Students. A Practical Approach. In Journal of Information Technology Education, 2005, 4; pp. 153–166. Thomas, O.; Walter, P.; Loos, P.: Design and usage of an engineering methodology for product-service systems. In Journal of Design Research, 2008, 7; pp. 177–195. Valacich, J. S.; Schneider, C.; Behl, R.: Information Systems Today. Managing in the digital world. Pearson, New Jersey, 2012. Warschauer, M.: The paradoxical future of digital learning. In Learning Inquiry, 2007, 1; pp. 41–49. Winter, R.: An Executive MBA Program in Business Engineering. A Curriculum Focusing on Change. In Journal of Information Technology Education, 2002, 1; pp. 279–288. Weber, C. et al.: Modelling of Product-Service Systems (PSS) Based on the PDD Approach: International Design Conference (Design 2004), 2004; pp. 547–554. Webster, J.; Watson, R. T.: Analyzing the Past to Prepare for the Future: Writing a Literature Review. In MIS Quarterly, 2002, 26; pp. xiii–xxiii. Zhang, D. et al.: Can e-learning replace classroom learning? In Communications of the ACM, 2004, 47; pp. 75!79. 224 Modeling Choreographies: BPMN 2.0 versus BPEL-based Approaches Oliver Kopp, Frank Leymann, Sebastian Wagner Institute of Architecture of Application Systems University of Stuttgart, Universitätsstraße 38, 70569 Stuttgart, Germany firstname.lastname@iaas.uni-stuttgart.de Abstract: Choreographies capture the collaboration aspects between two or more processes. Explicit choreography notations have been included in the upcoming version 2.0 of the Business Process Model and Notation language (BPMN 2.0). This paper presents a first evaluation of the choreography modeling capabilities of BPMN 2.0 and presents a summary of the evaluation of BPEL-based approaches. The result is that BPMN 2.0 does not support reference passing and is tightly tied to technical configurations. 1 Introduction The collaboration between two or more processes is captured by process choreographies [Pel03]. There are two paradigms of choreography languages available: interconnection models and interaction models [DKB08]. In both modeling styles, the participants interact with each other and activities are connected. On the one hand, an interconnection model connects communication activities belonging to two participants. Thus, each send/receive message exchange is expressed using a connection between participants. On the other hand, interaction models express each send/receive message exchange as atomic interaction. Generally said, the terms “interaction model” and “interconnection model” are derived from the way each modeling paradigm expresses a send/receive message exchange and not from the fact that activities are connected or general interactions between processes are presented. The current version of BPMN 2.0 [Obj10] supports both, interconnection models and interaction models. We use the requirements by Decker et al. [DKLW09] to evaluate the choreography capabilities of BPMN 2.0 and provide a comparison with BPEL-based choreography approaches. In this work, we dropped “R10: Integration with service orchestration languages”. BPMN 2.0 also offers modeling orchestration of Web services and thus a discussion of mapping concepts from BPMN 2.0 to BPEL is obsolete. In fact, it is possible that a workflow engine accepts both formats [Ley10]. A variant of the requirements by Decker et al. [DKLW09] is presented by Schönberger [Sch11]. In principle, “Decomposability” and “Standardization” have been added, whereas “Correlation” and “Message Formats” have been dropped. We did not adopt that requirements framework to keep the existing evaluations of BPELlight , WSFL, WS-CDL, Let’s Dance, BPMN 1.x, iBPMN, BPSS/UMM, and SCA comparable with our work. Our future 225 work is to consolidate these requirements with the work of Schönberger and re-evaluate all choreography languages using the consolidated requirements. Neither the requirements by Decker et al. nor by Schönberger take comprehensibility of the language itself into account. Such a quality assessment might be done by using the quality framework presented by Krogstie et al. [KSJ06]. 2 Chorographies in BPMN 2.0 In BPMN 2.0 interconnection models are implemented by collaboration diagrams. These diagrams consist of two or more pools, where each of them represents a participant in the overall collaboration. Within a pool, the internal process behavior of a participant is modeled with BPMN common elements (e. g., activities, events, and sequence flows). Alternatively, pools can be depicted as black boxes, i. e., no internal process behavior is modeled. In the discussion below we focus on pools that contain internal processes as they provide more information about the collaboration. A choreography language has to support multi-lateral interactions (requirement R1). Multilateral interactions are supported by the pools and message flows in BPMN collaboration diagrams. It must be possible to specify the participant topology, i. e. the number and types of participants involved in a choreography (R2). The participant types can be expressed by pools and by using attributes, the minimum and maximum number of participants can be specified. Hence, R2 is supported as well. The choreography language has to provide also means to model an arbitrary number of participants of the same type (“Service sets”, R3), where the concrete number is determined at runtime. Multiplicity can by indicated in BPMN collaborations by three black parallel lines in the bottom center of the pool, thus R3 is supported. Another important choreography feature is “reference passing” (R4), where participant A enables participant C to communicate with participant B by passing the reference of B to C. This is not explicitly covered by the BPMN specification. The only way to indicate that messages contain references are documentation elements. Message formats (R5) cannot be expressed by the graphical notation of BPMN, i. e., there exist no graphical elements in the specification to define the format of a message. A message, however, may have an optional itemRef property (which is invisible in the diagrams). This property represents an item definition, which contains a reference to a concrete data schema (e. g., XML schema), thus R5 is fully met. To enable an easy exchange of choreography implementations (as concrete WSDL portTypes and WSDL operations [W3C01]) the technical configurations of a choreography have to be interchangeable and should be separated from choreography model (R6). In BPMN collaborations, participants can be associated to interfaces (which are no graphical elements). These abstract interfaces may contain references that point to a corresponding technical implementation, such as WSDL portTypes. This, in turn, leads to the fact, that a reference has to be changed if the name of the portType has been changed, thus 226 requirement R6 is not supported. The modeling of time constraints (R7) has to be supported by choreographies, too. In BPMN collaborations they can be modeled by timer intermediate events. Another choreography requirement is “Exception handling” R8. This is also supported by BPMN collaborations. An exception can be caught and raised by error events. As choreographies may be enacted multiple times messages have to be routed to the correct process instance that belongs to the choreography instance, thus a message correlation mechanism is required (R9). In BPMN correlation information cannot be specified graphically in a diagram, but BPMN collaborations provide means to define correlation information for the collaboration (i. e., R9 is met). For each collaboration a property named correlationKey can be defined. This property consists of one or many correlation properties that provide expressions to extract certain data from the payload of a message in order to associate the message to a particular process instance. Interaction models are realized by choreography diagrams in BPMN 2.0. These diagrams define a special kind of processes that reflect the interaction sequence, i. e. the message exchanges between two or more participants (which are represented by pools in the collaboration diagrams). The atomic building block in choreography diagrams is the choreography task (briefly called “task” in the following). “[An atomic task] represents an Interaction, which is one or two Message exchanges between two Participants.” [Obj10]. Requirement R1 is satisfied, because the purpose of choreography diagrams is the definition of interaction behavior between two or more participants. If one participant has to interact with multiple partners, a task for each interaction can be created. Choreography diagrams have full support of requirement R2: One can specify the type of a service involved in a choreography diagram. It is not possible, however, to determine the exact number of participant instances involved in an interaction. Using the participantMultiplicity attribute, it is possible to specify minimum and maximum number of participants. Three black parallel lines in the bottom center of the participant bands indicate that multiple instances of a particular participant interact with another participant. Thus, requirement R3 is satisfied. There is no explicit support for reference passing mechanisms (R4) in choreography diagrams. As explained in the context of interconnection models, the only way to indicate that a message carries service references are natural language descriptions in documentation elements, which lack formality. Choreography diagrams support message formats (R5). Although messages cannot be graphically visualized in the choreography diagram, each atomic task contains one or more messages. As mentioned in the context of interconnection models, a message may have an optional itemRef property that contains a reference to a concrete data schema. Participants in collaborations can be associated to interfaces. This is also true for choreographies but as with collaborations an interface references to a portType (or any other technical implementation) by using its qualified name. Consequently, the reference has to be changed after the portType name has been changed. Thus, requirement R6 is violated 227 as the technical configuration cannot be interchanged without adapting the choreography accordingly. Requirement R7 (time constraints) is satisfied by BPMN choreography diagrams as timer intermediate events can be added to the choreography. A requirement that is not satisfied by BPMN choreographies is exception handling (R8): Exceptions are only visible to the participant where the error occurred. That means that the other participants are not aware of any exception that was thrown within a particular participant. As a consequence, they cannot handle this exception. The only way for a participant to inform the other participants about an exception are ordinary messages, i. e., there are no special error message types. Like in BPMN collaboration diagrams, correlation information (requirement R9) cannot be depicted in a choreography diagram either. BPMN 2.0 choreographies, however, provide a property named correlationKey to define correlation information, thus R9 is met. 3 BPEL-based Choreography Approaches BPEL supports modeling of single business processes. It does not directly support choreographies. Hence, BPEL4Chor [DKLW09] has been introduced to support interconnection models and BPELgold [KEvL+ 11] has been introduced to support interaction models. BPEL4Chor directly supports interconnection models. The behavior of each participant is modeled using BPEL. Each behavior description is called “participant behavior description”. Communication activities must not have WSDL-specific attributes such as partnerLink and operation. The interconnection to other participants is established by “message links”, which connect sending and receiving activities. A message link contains the attribute participantRefs, which lists the participant references transmitted on the message flowing on the message link. Message links themselves are listed in a “topology”. Besides message links, the topology contains a list of participant types (referring to participant behavior descriptions) and a list of participants and participant sets which denote the participants taking part in one instance of the choreography. Decker et al. [DKLW09] already evaluated BPEL4Chor using the requirements. We summarize the findings in the following. BPEL4Chor introduces a topology (R2) with sets of services (R3). BPEL4Chor allows an arbitrary number of participant types and thus supports multi-lateral interactions (R1). BPEL4Chor supports participant references by the attribute participantRefs on a message link (R4). Specification of message formats is fully supported by BPEL4Chor (R5). Technical configurations are stored in a separate grounding document, which enables interchangeability of technical WSDL information in different settings (R6). Time constraints may be specified using BPEL’s control flow constructs (R7). BPEL’s exception handling can be reused in BPEL4Chor (R8). Correlation may be specified on a name-basis or directly using message properties (R9). BPELgold is a choreography language providing interaction models using the control flow semantics of BPEL. “gold” stands for global definition. The complete language and an 228 evaluation of the requirements is presented by Kopp et al. [KEvL+ 11]. Here, we provide a summary of the language and the evaluation according to the requirements. BPELgold reuses the topology and the grounding of BPEL4Chor. The participant behavior descriptions are replaced by a single process interaction description. A message link of the topology relates a sending participant to a receiving participant and excludes concrete activities. The attribute participantRefs still exists. The process interaction description is a BPEL process following the Abstract Process Profile for Basic Interaction Models. “Basic” denotes that only interactions between listed participants are allowed. BPELgold introduces the Abstract Process Profile for Extended Interaction Models, where a global observer may also interact with the choreography. This is used for runtime compliance checking of choreographies as described by Kopp et al. [KvLN08]. This profile is out of scope of this paper. In the case of the basic profile, BPEL’s communication activities are disallowed in BPELgold . Interactions are solely described by an interaction activity. This activity presents an atomic message exchange between two participants: One participant sends a message and another participant receives that message. As BPELgold builds on BPEL4Chor, it supports a topology (R2) with sets of services (R3). BPELgold also supports arbitrary numbers of participant types and thus multi-lateral interactions (R1). The attribute participantRefs is still present in message links and thus participant references can be passed over a message link (R4). Message formats can be specified using variables in the process model (R5). The concept of a grounding is still present (R6): In a grounding, an interaction activity is assigned a partnerLink/operation combination, which in turn is used in the services implementing the described participants. Time constraints can be modeled using the constructs provided by BPEL (R7). BPELgold supports the exception handling mechanisms of BPEL. Thus the exceptional path through the choreography model can be explicitly described (R8). BPEL’s concept of correlation is reused in BPELgold : Each interactionActivity contains a correlationSet element referring to a correlation set used for correlation (R9). BPELgold can be mapped to BPEL4Chor: each interactionActivity is split into an invoke/receive pair. The name of each communication activity is generated. Thus, all information of a BPEL4Chor message link is available. 4 Conclusion and Outlook We compared the choreography modeling capabilities of BPMN 2.0 using the evaluation criteria of Decker et al. [DKLW09]. For each requirement, we showed the constructs offered by BPMN 2.0 to implement each requirement. Section 3 summarized the evaluation of BPEL-based approaches. Table 1 summarizes the evaluation. On the one hand, it turns out, that BPEL4Chor and BPELgold provide a complete support of the requirements, whereas BPMN 2.0 lacks support: Reference passing and interchangeability of technical configurations are not fully supported. On the other hand, only BPMN offers a full graphical notation for both interaction models and interconnection models. Thus, a next step is a detailed investigation of the integration of BPMN 2.0 with BPEL4Chor and BPELgold . 229 Modeling Style R1. Multi-lateral interactions R2. Service topology R3. Service sets R4. Reference passing R5. Message formats R6. Interchangeability of technical configurations R7. Time constraints R8. Exception handling R9. Correlation BPMN 2.0 Collaboration interconnection + + + – + – BPMN 2.0 Choreography interaction + + + – + – BPEL4Chor BPELgold interconnection + + + + + + interaction + + + + + + + + + + – + + + + + + + Table 1: Assessment of BPMN 2.0 and BPEL-based approaches This may be an extension of BPMN to support all constructs of BPEL4Chor similar to the approach taken by Pfitzner et al. [PDKL07] in the case of BPMN 1.0 and BPEL4Chor. Currently, there exists a mapping of BPMN 1.0 to BPEL4Chor [PDKL07] and no mapping of BPMN 2.0 to BPEL4Chor. In case such a mapping is available, BPMN 2.0 collaborations can be transformed to BPEL4Chor choreographies. Such a transformation would lead to a fulfillment of requirement R6: The technical configuration is not done in the BPMN 2.0 model, but using the mechanisms offered by BPEL4Chor. References [DKB08] G. Decker, O. Kopp, and A. Barros. An Introduction to Service Choreographies. it Information Technology, Special Issue on Service-oriented Architectures, 50(2), 2008. [DKLW09] G. Decker, O. Kopp, F. Leymann, and M. Weske. Interacting services: from specification to execution. Data & Knowledge Engineering, 68(10):946–972, April 2009. [KEvL+ 11] O. Kopp, L. Engler, T. van Lessen, F. Leymann, and J. Nitzsche. Interaction Choreography Models in BPEL: Choreographies on the Enterprise Service Bus. In S-BPM ONE 2010, CCIS. Springer, 2011. J. Krogstie, G. Sindre, and H. Jørgensen. Process models representing knowledge [KSJ06] for action: a revised quality framework. European Journal of Information Systems, 15(1):91–102, 2006. [KvLN08] O. Kopp, T. van Lessen, and J. Nitzsche. The Need for a Choreography-aware Service Bus. In YR-SOC, 2008. [Ley10] F. Leymann. BPEL vs. BPMN 2.0: Should You Care? In 2nd International Workshop on BPMN, LNBIP. Springer, 2010. Object Management Group. Business Process Model and Notation (BPMN) Version 2.0. [Obj10] OMG, 2010. [PDKL07] K. Pfitzner, G. Decker, O. Kopp, and F. Leymann. Web Service Choreography Configurations for BPMN. In WESOA, volume 4907 of LNCS. Springer, 2007. C. Peltz. Web Services Orchestration and Choreography. IEEE Computer, 36(10):46–52, [Pel03] 2003. [Sch11] A. Schönberger. Do We Need a Refined Choreography Notion? In ZEUS. CEURWS.org, 2011. [W3C01] W3C. Web Services Description Language (WSDL) 1.1, March 2001. 230 Process Model Verification with SemQuu Michael Fellmann, Oliver Thomas Institut für Informationsmanagement und Unternehmensführung Universität Osnabrück Katharinenstr. 3 49074 Osnabrück, Germany {michael.fellmann, oliver.thomas}@uni-osnabrueck.de Abstract: In this contribution, we present an overview of our ongoing work in developing an integrated tool support for semantic process model verification. We present some of the requirements and insights gained by the implementation of a platform for semantic process model verification. The platform is based on OWL and SPARQL and provides for a user-friendly way of semantic model verification. First empirical evaluations have been very promising and confirm that the tool can be used to effectively query and verify semi-formal process knowledge. 1 Introduction 1.1 Background A fundamental idea in the context of the model-driven development of information systems is to use models to manage the complexity accompanied with the development task. They provide a means for understanding business processes and serve for optimization, reengineering, and development of supporting IT systems. Especially in regard to the latter aspect, the quality of the models is of vital importance since it directly affects the quality of the information systems developed on the basis of the models. According to ISO 8402, quality is “the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs”. One fundamental aspect of model quality is the correctness of a model. There has been extensive research regarding syntactical correctness. In contrast to that, approaches to verify the semantic correctness, i.e. the correctness of the model contents, have been considered less frequently. With the term “verification”, we denote ensuring correctness with respect to explicitly stated requirements. In contrast to that, validation means the eligibility of a model in respect to its intended use [De02, p.24] – in other words: if the criteria is something outside the model [Me09, p.2]. Following this distinction, we call the procedures to ensure semantic correctness “semantic verification”. A major problem regarding semantic verification is how to automate it. This problem is rooted in natural language being used for labeling model elements, thus introducing terminological problems such as ambiguity (homonyms, synonyms) and other linguistic 231 phenomena. Model creators and readers do not necessarily share the same understanding as the concepts they use are usually not documented and mix both discipline-specific terminology and informal, ordinary language. Hence, it is hard for humans to judge if a model is semantically correct and almost impossible for machines (apart from using heuristics) because the model element labels are not backed with machine processable semantics. The result is that the machine cannot interpret the contents of model elements. Therefore, we have developed an approach to encode the model element semantics in a precise, machine readable form using OWL ontologies. On top of the ontology-based representation, SPARQL-queries are used to check the correctness of a model based on its graph structure. We use this query language as (a) it is a language which has been standardized by the World Wide Web Consortium (W3C) and gained broad acceptance in the Semantic Web and AI community, (b) it provides a simple structure for queries consisting of triples which intuitively reflect the structure of process graphs and (c) the query language is not specialized to any specific process modeling language such as EPC, BPMN or UML Activity Diagrams. The approach is described in more detail in [FeTh11]. In contrast to our previous work where we elaborated on our concept of semantic verification, in this contribution we concentrate on the description of our prototypical implementation. We describe the requirements, design decisions and insights gained by extending a modeling tool with support for semantic verification. 1.2 Related Work Approaches to ontology-based semantic verification can be found e.g. in the context of Semantic Web Services. Semantically annotated process models are verified with an emphasis on logical preconditions and effects which are specified relative to an ontology [Dr07], [We09], [WHM10]. These approaches usually require both the annotation of preconditions and effects and hence enable to check if the model is consistent. They do not build upon a formal representation of the (intentional) semantics of individual model elements (i.e. what is “inside the box” of a model element). In contrast to that, the underlying paradigm of our approach is capturing the semantics of model elements by using a single annotation of a model element in order to associate it with its intended meaning explicitly specified in a formal ontology. Semantic constraints are then formulated as SPARQL queries which are executed against the model repository. Such queries focus constraints related to the structure of a model (e.g. to verify the absence of an anti-pattern) and are in this respect orthogonal to approaches emphasizing the correct execution of process instances [Ly09]. In respect to the IT-support of SPARQL queries, query builders such as Konduit VQB have been developed [AMH10]. Whereas these tools provide complex forms aiming at a general-purpose support for SPARQL, our approach is tailored to query process models. We provide a simple yet powerful user interface and we have evaluated the effectiveness in a user experiment. 232 2 Requirements In this section, we describe basic requirements regarding the functionality of the integrated tool support for our approach to semantic model verification described in [FeTh11]. To explore the general topic of queries and search in process models, we conducted a survey. The participants of the survey (50 from both academia and practice) clearly favored form-based approaches over all other approaches for querying model contents. As form-based approaches require less knowledge in comparison to the usage of a query language, it can be concluded that the users want to have a simple and userfriendly way of specifying queries. However, by relying exclusively on form-based queries, much of the freedom and flexibility a query language such as SPARQL for querying graph like structures offers is lost. We therefore suggest using a hybrid approach where triple patterns of SPARQL queries can be constructed using a form and adapted as plain-text manually. In order to execute multiple queries e.g. when checking if a set of constraints is met, the tool has to provide for the batch-execution of queries. Finally, we do not want to confine ourselves to a specific modeling language such as BPMN or EPC. Rather, the tool should transform different model representations into the ontology-based process representation devised in our previous work. Below, we summarize the requirements. (R1) Form-based, fail-safe query construction: Since our survey revealed that formbased approaches of query construction are favored over other alternatives, the tool has to offer support for query construction using forms. The user should construct a query exclusively by interacting with the form, i.e. no textual input should be required. Only valid queries both in respect to syntax and semantics should be producible with the formbase query construction feature. (R2) User-friendly query refinement: Since we propose the usage of SPARQL for querying process models and for specifying semantic constraints, the user should be able to use the full expressivity of this query language. However, the user should be supported in refining a query which in its initial form is generated using the form-based approach of query construction (cf. R1). (R3) Execution of batch queries: In order to execute multiple queries at once, the tool has to provide for the batch-execution of queries. The results should be summarized in a report whereby it should be possible to assign a type to each query result as either being information, a warning or an error. (R4) Support of multiple modeling languages: In order to achieve a broad applicability of the tool, it should not be dependent on a specific modeling language such as the EPC, BPMN etc. but instead should be generic. Moreover, other requirements such as performance and scalability were considered as well during the development process. Due to space limitations, we have not listed them as requirements but mention them in the appropriate sections of the platform description. 233 3 Using SemQuu for Process Model Verification In the following, we describe the tool we have developed for process model verification. The tool is called SemQuu – Semantic Query Utility, since much of the functionality is also relevant when exploring ontologies in general. SemQuu is implemented using the Jena library (jena.sourceforge.net), the Pellet inference engine (pellet.owldl.com), the Tomcat web server and JSP, XSLT, JavaScript, CSS and HTML for the user interface. 3.1 Import of Process Models Process models can be imported from arbitrary tools in arbitrary formats, since they can be transformed on the server into the ontology-based representation which is accomplished by a plugin-converter for each format (R4 is met). As an example, we have implemented an extension of Visio which can export EPC process models being annotated with ontology concepts (see Fig. 1 for an illustration of the following procedure). For export from Visio, we use the standard EPML format (Event-driven Process Chain Markup Language) with special attributes capturing the semantic annotation of the model. After having been exported from Visio to SemQuu, the model is transformed to an OWL-DL ontology and added to the repository (cf. Fig 1 right). Fig. 1 SemQuu Converter and Repository 3.2 Querying the Semantic Process Repository using SPARQL An overview of SemQuu is provided by Fig. 2 (B). In order to query the repository of ontology-based process representations with SPARQL, the user can use a simple formbased query builder (A) for successively constructing a graph pattern (R1 is met). This is done by inserting multiple triple patterns with the help of drop-down list boxes (A) which are aware of rdfs:domain and rdfs:range information so that no semantically wrong query can be constructed (R1 is met). 234 Fig. 2 Overview of SemQuu Moreover, drop-down list boxes are dynamically updated upon selection of a value in one of the boxes. Alternatively to the drop-down list boxes, the user can leverage the full expressivity of SPARQL by using the text area input field. Moreover, when the user modifies the query she or he is supported by an “intelligent” auto-completion feature (D) which is fully aware of the ontology schema and instance data and only proposes meaningful suggestions (R2 met). When queries are executed in batch mode, the result of the queries can be displayed as an information, warning or error with respective graphical symbols appearing for each type (C). The result for each query is initially collapsed but can be unfolded if the user clicks on the “+” sign symbols (R3 is met). 4 Evaluation In order to measure the effectiveness of SPARQL queries for the task of semantic correctness checking, we conducted an experiment with 21 participants. We have described this experiment in more detail in [FeTh11]. We give a short overview of the results of this experiment here. We used models in three different sizes with 11, 39 and 217 model elements. The participants had to answer 10 questions per model (a) by browsing and searching in the model with the tool Microsoft Visio or (b) by using SemQuu. We conducted the experiment without the form-based query construction feature since it was not been available at the time we conducted the experiment (however, we plan to re-evaluate the tool). Fig. 3 shows the time required for answering the 10 questions for each of the three models in relation to the model size. As can be seen easily, at first there is a learning curve when using SPARQL. When the model size exceeds approx. 190 model elements, the query language outperforms manual search. 235 Time 00:23:02 00:20:10 00:17:17 00:14:24 00:11:31 00:08:38 00:05:46 00:02:53 00:00:00 Brow sing SPARQL 0 75 small 150 225 medium large Model size Fig. 3 Time Needed to Answer the Questions Dependent on Model Size 5 Conclusion and Outlook In this contribution, we have introduced SemQuu, our prototype for semantic process verification. Results of an initial evaluation regarding the query formulation have been very promising. The tool is under active development, currently we are working on improvements regarding the import and export of model data from Microsoft Visio. Literature [AMH10] Ambrus, O.; Möller, K.; Handschuh, S.: Konduit VQB: a Visual Query Builder for SPARQL on the Social Semantic Desktop. In (Handschuh, S. et al. Eds.): Proc. of VISSW 2010, Hong Kong, China, 2010; 5 Pages. [De02] Desel, J.: Model Validation – A Theoretical Issue? In (Esparza, J., Lakos, C. Eds.) Proc. of ICATPN 2002, Adelaide, Australia. Springer (LNCS 2360), 2002; pp. 23–43. [Dr07] Drumm, C. et al.: Dynamic Composition Reasoning Framework and Prototype. In: Project IST SUPER, Deliverable 3.2, SAP, 2007. [FeTh11] Fellmann, M.; Thomas, O.; Busch, B.: A Query-driven Approach for Checking the Semantic Correctness of Ontology-based Process Representations. In Proc. of BIS 2011, Poznan, Poland, 2011. Springer (LNBIP 87), Berlin; pp. 62–73. [Ly09] Ly, L.T. et al.: On enabling integrated process compliance with semantic constraints in process management systems. In: Information Systems Frontiers, 2009; pp. 1-25. [Me09] Mendling, J.: Empirical Studies in Process Model Verification. In (Jensen, K.; van der Aalst, W.M.P. Eds.): Transactions on Petri Nets and Other Models of Concurrency II. Springer (LNCS 5460), Berlin, 2009; pp. 208–224. [W09] Weber, I.M.: Verification of Annotated Process Models. In: Semantic Methods for Execution-level Business Process Modeling, Springer (LNBIP 40), Berlin, 2009; pp. 97–148. [WHM10] Weber, I.; Hoffmann, J.; Mendling, J.: Beyond soundness: on the verification of semantic business process models. In: Distributed and Parallel Databases (27), 2010; pp. 271–343. 236 Designing a Risk-based Partner Selection Process for Collaborative Cloud Computing Environments Benedikt Martens1, Novica Zarvi!2, Frank Teuteberg1, Oliver Thomas2 1 Accounting and Information Systems Information Management and Information Systems University of Osnabrueck Katharinenstr. 1-3 49069 Osnabrueck {benedikt.martens; novica.zarvic; frank.teuteberg; oliver.thomas}@uni-osnabrueck.de 2 Abstract: Cloud Computing represents a shift in technology and IT (information technology) service management and it opens up possibilities to build new organizational configurations. As in IT outsourcing, the selection of the right partner/vendor is of crucial importance. Thus, in this article we present a partner selection process for four Cloud Computing Environments: public cloud, community cloud, cloud chain and industrial cloud. We included data sensitivity and the risk attitude of the decision maker as major decision factors for partner selection. The constructed IT artifact (i.e. partner selection process) is evaluated by means of a conceptual evaluation (expert interviews) that demonstrates the applicability of the selection process. 1 Introduction The advent of the internet, as well as advances in related concepts and technologies (as e.g. Cloud Computing) have led to an increase in research on Collaborative Networks and inter-organizational business practices [CA05]. In the course of that, researchers increasingly focused on the inter-organizational use of IT instead of taking a solely intraorganizational view (cf. [KD96]). Cloud Computing is a new paradigm for the delivery of scalable IT services via the internet on a pay-per-use basis [Ar10]. In this context, the term ‘cloud’ refers to data centers that offer virtualized computing resources and services. The combined investigation of Cloud Computing Services and Collaborative Networks results in new collaboration types with a focus on resource sharing. In this paper we posit that Cloud Computing works on the same basic principles as all Collaborative Networks: two or more businesses that are largely autonomous and geographically distributed collaborate with each other and are supported in this by IT networks [CA05, WRT09]. Thus, the sourcing of Cloud Computing services always implies some degree of dependency on external partners and a certain level of risk for each participating unit [KD96, Ar10]. One of the biggest challenges regarding the success of Collaborative Networks is the selection of partners in inter-organizational business settings [WCB91]. In view of all this we propose a partner selection method for conceivable Cloud Computing Environments with a focus on risk and security factors. 237 We aim at developing a new partner selection method for the field of Cloud Computing. The conceptual elaboration of the IT artifact is based on a systematic literature review focusing on terms from the field of Cloud Computing and provider/vendor selection that have been applied to publisher independent journal data bases [MT09]. Overall we identified a sample of 113 articles published in journals and conference proceedings. Finally we improved the artifact by means of three expert interviews. The interviewees were experienced practitioners and academics with 3 to 10 years of work experience in the field of Collaborative Networks, Partner Selection and IT outsourcing. 3 Reviewing Cloud Computing and Partnership Formation Researchers have especially focused on gaining more insights into Cloud Computing and its multiple facets. For instance, Youseff et al. [YBS08] propose an ontology, which illustrates the relevant factors of Cloud Computing and their relationships. As yet, little research has been conducted on the success factors and the risks associated with Cloud Computing Services [MT09]. Koehler et al. [KAD10] found that the average reputation of the Cloud Computing Service provider and the use of standard data formats are more important than financial aspects such as cost reduction or pricing tariffs. Armbrust et al. [Ar10] present a list of ten obstacles for Cloud Computing, of which the following four are assumed to affect adoption: availability/business continuity, data lock-in, data confidentiality and auditability. We found that several authors point out the importance of risk and security methods for Cloud Computing Services [YBS08, MT09]. From a vendor perspective, there are some obstacles affecting the growth of Cloud Computing as well as policy and business issues, e. g. data transfer bottlenecks [Ar10]. Nevertheless, Cloud Computing facilitates the introduction of new products and services without large investments in IT infrastructure [Pu09]. Pricing strategies and revenue models are suggested for instance by Pueschel et al. [Pu09] in order to exploit the economic opportunities offered by this emerging paradigm. The literature review revealed that only little research has been conducted in the field of Collaborative Networks. The only article on this topic that we could identify is the one by Wlodarczyk et al. [WRT09], who deal with the aggregation of several private Clouds to reduce security risks, which can also be regarded as a form of Collaborative Networks. The duration of collaborations between different companies or organizations can be described by the so-called life cycle of enterprise networks [TJ01]. By and large, the enterprise network life cycle can be divided into four different phases: a preparation phase (preparing, first sourcing of partners etc.), a formation/setting up phase (final partner selection, legal issues, contracts etc.), an operation phase (daily management of the network) and a dissolution phase (decomposition of the network). Therefore, partnership formation happens both during the preparation phase and in the formation/setting up phase. Partner identification is concerned with the identification of possible business partners. For example, Large [La09] distinguishes – next to the different request types – also the internet as a source for identifying conceivable partners. Additionally he lists classical sources such as personal contacts, professional journals, annual reports, trading catalogues and alike. Apart from these two categories, it is also conceivable to identify possible partners indirectly, that is, via intermediaries. 238 What all these categories have in common is the fact that they are self-initiated approaches. Partner selection, as the second and final step in the process of partnership formation, can be performed by means of several methods and techniques. In the literature review by Weber et al. [WCB91] and Zhang et al. [Zh04] 123 articles have been reviewed paying special attention to the criteria and methods used in the partner selection process. As regards the methods applied, the following three categories were initially proposed by Weber et al. [WCB91]: linear weighting approaches, mathematical programming techniques and statistical/probabilistic approaches. We have added another category to this three-way categorization, which includes all other approaches found in the literature that did not fit any of these three categories – as, for instance, serious games and simulations [Ha08], agent-based approaches [Pe07] or activity-based costing [RK97]. However, the results of the literature review give the impression that the selection of partners in the context of Cloud Computing has not yet received sufficient attention from the research community. To the best of our knowledge, we are the first researchers to apply the concept of partner selection to the realm of Cloud Computing Environments with a specific focus on risk and security. 4 Collaboration Types in Cloud Computing Environments A selecting process for Cloud Computing partners/vendors needs to consider the individual characteristics of each Cloud Computing Environment in order to be effective. The following typology was developed deductively on the basis of scientific literature and evaluated by means of expert interviews. In Thompson’s [Th67] seminal work on organizational theory, he described pooled, sequential and reciprocal interdependencies for an intra-organizational perspective, which were later mapped to the interorganizational context by Kumar & van Dissel [KD96]. In the field of Cloud Computing we have identified collaboration configurations that share the same structural properties as these inter-organizational system types. This analogy led to the definition of three distinct Cloud Computing types which are conceptually depicted in Figure 1. The following description points to security and risk-related aspects that are relevant for the development of a partner selection method. In Pooled Cloud Computing one business actor sources a service from the central point. This might be represented either by a (standard) public cloud environment or a community cloud environment [Ar10]. In contrast to public clouds, community clouds are only available for members of a specific community (i. e. shared needs of a business community), where interdependencies remain the same, which is the reason why both belong to the same collaboration type. Community clouds provide a slightly higher security level than public clouds [WRT09]. Public availability has an enormous impact on risk management, for it requires high risk management effort, whereas limited availability to specific communities reduces the effort. Sequential Cloud Computing includes public clouds and represents a chain of interdependencies by means of service flows (cloud chain). The access to this type of cloud is usually open, resulting in a low security level comparable to that of (standard) public clouds. Finally, in Networked Cloud Computing the output of each point can become input for the other points, as happens, for example, in so-called industrial clouds [WRT09]. However, the fact that they constitute a closed network of private clouds guarantees for a high level of security [WRT09]. 239 Figure 1. A comprehensive and risk-based overview of Cloud Computing Environments. 5 Development of a Partner Selection Process The developed approach combines a standard partner selection process [CNR95, MF97] with a special focus on risk and security issues in Cloud Computing. The process is illustrated in Figure 2. The preparation phase starts with the prerequisites of a sourcing decision: the selection of a particular Cloud Computing Environment and the identification of potential partners. The formation phase comprises the actual partner selection and the initialization of the partnership. In addition to the actual process we added methods, theories and documents to individual process steps. Since we investigate the outsourcing of standardized Cloud Computing Services, we assume a newly arising requirement as the first process step (e. g. the demand for a new IT service triggered by a new business opportunity). This new requirement needs to be documented, analyzed and aligned to the business strategy and the IT strategy of the focal company [MF97]. This step is of particular importance for the follow-up activities because it accounts for security and risk requirements, too. The make or rent decision is made on the basis of the availability of internal resources and the ratio of production and sourcing costs. Next, the company needs to determine its requirements regarding the risk and security level of the IT service. During this step the risk attitude of the decision maker needs to be taken into account. If the company considers a relatively low security level sufficient and decides to enter an open access cloud it needs to distinguish between the Cloud Computing Environments “public cloud” (pooled Cloud Computing) and “cloud chain” (sequential Cloud Computing) (cf. Figure 1 and Figure 2). Within the former environment the focal company acts as an end user and within the latter environment as an intermediator. For the following steps of this track, we recommend applying the approaches discussed in Section 3. On the other hand, the process paths for closed access Cloud Computing types (community cloud and industrial cloud) with medium and high security levels can support companies in their search for existing community clouds or industrial clouds. Following the identification of suitable networks, the decision-making company retrieves more detailed information on these networks in order to review them and to set 240 up a ranking list. Finally, the company submits a request for membership to the best fitting network. If access to this network is denied, the next best one is applied for. Figure 2. Partner selection process for specific Cloud Computing Environments. 6 Conclusions and Outlook The presented methodic approach supports companies in selecting partners for collaborations in Cloud Computing environments and provides a strategic framework for such collaborations from a managerial, technological and organizational perspective. In this context, a strong focus was put on risk and security issues. In particular, the method serves to support companies with knowledge in the field of vendor management in Cloud Computing. We built the conceptual model (cf. Figure 2) on a deductive theoretical basis (theories and methods) and improved it iteratively by means of semistructured expert interviews [Wal06]. Limitations of our approach lie in the limited number of decision factors we draw on (security and risk issues). Furthermore, we concentrated on the organizational forms Cloud Computing offers to companies. We are planning to adapt our method to the requirements of the different Cloud Computing Service types, which will mainly result in a modification of the first part of the process. 241 Furthermore, a closer look at interdependencies within clouds or between the participating collaboration partners could lead to important insights regarding the discussed Cloud Computing Environments. There are many interdependencies within industrial clouds. Partners in such a network are strongly dependend on each other, which offers new business opportunities, but also new risk factors. References [Ar10] Armbrust, M.; Fox, A.; Griffith, R.; Joseph, A.D.; Katz, R.H.; Konwinski, A.; Lee, G.; Patterson, D.A.; Rabkin, A.; Stoica, I.; Zaharia, M.: A View of Cloud Computing. In Communications of the ACM, Vol. 53, No. 4, 2010; pp. 50-58. [CA05] Camarinha-Matos, L.M.; Afsarmanesh, H.: Collaborative Networks: A New Scientific Discipline. In Journal of Intelligent Manufacturing, Vol. 16, No. 4-5, 2005; pp. 439-452. [CNR95] Chaudhury, A.; Nam, K.; Rao, H.R.; Management of Information Systems Outsourcing: A Bidding Perspective. In Journal of MIS, Vol. 12, No. 2, 1995; pp. 131–159. [Ha08] Hans, C.: Supporting partner identification for virtual organisations in manufacturing. In Journal of Manufacturing Technology Management, Vol. 19, No. 1, 2008, pp. 497-513. [KAD10]Koehler, P.; Anandasivam, A.; Dan, M.A.: Cloud Services from a Consumer Perspective Cloud Services from a Consumer Perspective. AMCIS 2010, Peru. [KD96] Kumar, K.; v. Dissel, H.: Sustainable Collaboration: Managing Conflict and Cooperation in Interorganizational Systems. In MISQ, Vol. 20; No. 3, 1996; pp. 279-300. [La09] Large, R.: Strategisches Beschaffungsmanagement – Eine praxisorientierte Einführung. Gabler, Wiesbaden, Germany, 2009. [MT09] Martens, B.; Teuteberg, F.: Why Risk Management Matters in IT Outsourcing - A Systematic Literature Review and Elements of a Research Agenda. ECIS 2009, Italy. [MF97] Michell, V.; Fitzgerald, G.: The IT outsourcing market-place: vendors and their selection. In Journal of Information Technology, Vol. 12, No. 3, 1997; pp. 223-237. [Pe07] Petersen, S.: Virtual enterprise formation and partner selection. In International Journal of Networking and Virtual Organisations, Vol. 4, No. 2, 2007; pp. 201-215. [Pu09] Pueschel, T.; Anandasivam, A.; Buschek, S.; Neumann, D.: Making Money with Clouds – Revenue Optimization Through Automated Policy Decisions. ECIS 2009, Italy. [RK97] Roodhooft, F.; Konings, J.: Vendor selection and evaluation an Activity Based Costing approach. European Journal of Operational Research, Vol. 96, No. 1, 1997; pp. 97-102. [TJ01] Thoben, K.-D.; Jagdev, H.: Typological issues in enterprise networks. In Production Planning & Control, Vol. 12, No. 5, 2001; pp. 421-436. [Th67] Thompson, J.D.: Organizations in Action: Social Science Bases of Administrative Theory. McGraw-Hill, New York, USA, 1967. [Wal06] Walsham, G.: Doing Interpretive Research. In European Journal of Information Systems, Vol. 15, No. 3, 2006; pp. 320-330. [WCB91]Weber, C.A.; Current, J.R.; Benton, W.C.: Vendor selection criteria and methods. In European Journal of Operational Research, Vol. 50, No. 1, 1991; pp. 2-18. [WRT09]Wlodarczyk, T.W.; Rong, C.; Thorsen, K.A.H.: Industrial Cloud: Toward Interenterprise Integration. In LNCS 5931, Springer, Berlin, 2009; pp. 460–471. [YBS08] Youseff, L.; Butrico, M.; da Silva, D.: Toward a Unified Ontology of Cloud Computing. In 2008 Grid Computing Environments Workshop, Austin, USA, 2008. [Zh04] Zhang, Z.; Lei, J.; Cao, N.; To, K.; Ng, K.: Evolution of supplier selection criteria and methods. In Proceedings of the Second Globelics Conference Innovation Systems and Development, Emerging Opportunities and Challenges, Beijing, China, 2004. 242 Introducing a Co-Creation Perspective to Service Business Models Andreas Zolnowski, Martin Semmann, Tilo Böhmann ISS International Business School of Service Management Hans-Henny-Jahnn-Weg 9 22085 Hamburg zolnowski@iss-hamburg.de Institut für Informatik Universität Hamburg Vogt-Kölln-Straße 30 22527 Hamburg semmann@informatik.uni-hamburg.de boehmann@informatik.uni-hamburg.de Abstract: Due to the growing importance of services for many companies and the resulting transformation of product based business models to service based business models, the paper focuses on the link between business models and services. For this purpose the business model canvas of Osterwalder is adapted to address the shortcoming relating to co-creation of extant business models. 1 Introduction Services are a key driver of growth and profitability for many companies [CS06]. Particularly firms in technology industries, such as IT, aerospace, medical technology, and automotive capture an increasing share of their income and profits with services [Ne08]. Thus, for these enterprises, services have become an essential part of their business models, leading more and more of these companies to transform their product based business models to service based business models. According to this transformation approaches for modeling are necessary. As a recent study shows, extant business model approaches have a lack in focusing specific aspects regarding to services [ZB11]. This paper therefore proposes the use of an adaptation of Osterwalder´s business model canvas to support the modeling of service business models. The remainder of the paper is structured as follows. Conceptual foundations about the understanding of business models in general and the business model canvas of Osterwalder as well as a general understanding of co-creation are given in chapter two. Based on this theoretical background in chapter three we derive the problem of considering service specific aspects in recent business model approaches. Moreover, we adapt the business model canvas of Osterwalder to match the requirements of service based business models. Finally we sum up the findings and give an outlook. 243 2 Conceptual foundations 2.1 Business models The academic literature offers a variety of possible conceptualizations of the business model construct. Recently, however, the different approaches seem to converge. AlDebai [Al10] summarizes a business model as “[...] an abstract representation of an organization, be it conceptual, textual, and/or graphical, of all core interrelated architectural, co-operational, and financial arrangements designed and developed by an organization, as well as all core products and/or services the organization offers based on these arrangements that are needed to achieve its strategic goals and objectives.” [Al10]. Similarly Osterwalder [Os04] defines a business model as a “[...] conceptual tool that contains a set of elements and their relationships and allows expressing a company's logic of earning money. It is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams.” [Os04]. Osterwalder also developed the business model canvas, which represents a visualization of the business model dimensions [OP10]. We decided to use this approach by Osterwalder, because of the systematic and easy use of the structure as well as the handy visualization. Figure 1 shows the Osterwalder business model canvas which is based on nine different dimensions. Key Ressources Partner Key Activities Value Proposition Customer Relationship Customer Channel Cost Structure Revenue Streams Figure 1: Business model framework (based on [OP10]) 2.2 Co-creation During the last decades the perspective of value creation turned from a value-inexchange view where value for customers is embedded in products to a value-in-use view where value for customers is generated during the value-generating processes [Gr08]. This reflects the shift from a traditional goods-dominant logic with the focus on the exchange of goods to a service-dominant logic focusing on the creation of value [VL06]. According to this value is not created by buying products but by using them in a specific context [GKW11]. This reflects renunciation from distinct roles of customers and producers towards a broad engagement of the customer in value creation [PR04]. 244 This new perspective emphasizes on the understanding of the customer as part of valuecreation [ETG10][SP08]. From this point of view the customers can tailor the product or service pursuant to their needs, which results in an enhanced value created [KMJ08]. This also implies that customers can be part of the value creation along the complete value creating activities e.g. maybe from the development to the delivery of a product or service by providing customer-specific knowledge [GKW11]. After a brief introduction into the basics of the business model and the co-creation, the main problem of the existing business model construct will be outlined and a possible solution will be introduced. 3 Service Business Models 3.1 Problem The business model construct will be used in order to analyse, describe and evolve the business model of products as well as services [ZB10]. Nevertheless, the consideration of business models has a lack of service-specific aspects. One important gap can be found in the structure of a business model. Co-creation, as a key characteristic of services, is not considered in most business model approaches [ZB11]. If it is considered, like in the Osterwalder Business model canvas, then only with little impact on the whole business model. For example Osterwalder limits co-creation to the customer relationship dimension [OP10]. This aspect is emphasized by the graphical illustration of the business model (figure 1). The business model canvas and the arrangement of the nine dimensions follow a goodsdominant logic view, where the dimensions are organized along a value chain. This chain starts with partners and key resources as well as key activities leading to the value proposition and at the end to the handling of the customer. This structure suggests that neither customers can participate in the value creation nor partners are involved in customer-specific aspects of the business model. 3.2 Proposal for a solution A possible way to address the described problem is to change the perspective on business models from a product to a service based point of view. To achieve this it is necessary that the framework permits a structure where the customer can be part of all aspects of the business model. A possible way for this is to change the composition of the nine blocks in Osterwalder´s business model canvas. The new structure is given in figure 2. 245 Customer Cost Structure Key Ressources Key Activities Value Proposition Customer Relationship Channel Revenue Streams Partner Figure 2: Adapted business model canvas (based on [OP10]). As figure 2 shows by encompassing the rest of the blocks with customers as well as partners the deep integration into the value co-creation is represented. With this adaptation it is possible to reflect business models where a customer may have influence on each dimension of the business model. In the following examples are given, which represent potential resources of co-creation. In many cases of service provision there is a need for customer integration. This is due to the fact that most services need to be provided individually for the customer. This leads to a dynamic role of the customer in the service provision where the provider´s mission is to help the customer to create value according to the specifications [GR11]. The value creation is focusing on shared monetary benefits and revenue, for example, sharing of financial gain and gaining joint contracts. Moreover, the relationship with the customer can be designed based on the desired customer experience. Analogous to this the channel has to be chosen. Further, customers have to be integrated into communication, sales and distribution as well as into open innovation processes, for example, through social media. On the one hand, customers can provide resources like infrastructure or technology and on the other hand they can influence the selection and use of resources. The service provision is directly influenced by the customers and delivered by joint activities. Depending on the objectives of the service provision costs are borne by customers. Table 1 sums up the outlined impacts of co-creation in service business models. Element Cost Structure Key Resources Key Activities Value Proposition Customer Relationship Channel Revenue Streams Customer perspective – Evidence of co-creation in business model elements • Cost incurred / borne by customers • Customer providing resources • Customers influence on resource selection and use (e.g. selecting a specific consultant or varying volume of demand) • Joint activities • Customers influence on activities • Specification of how service provider helps customers to create value • Desired customer experience • Derived customer experience • Open innovation • Integration of customers in communication, sales and distribution (e.g. through social media) • Shared monetary benefits / revenue (e.g. sharing of financial gain and gaining joint contracts) Table 1: Customer perspective –Evidence of co-creation in business model elements 246 In addition to the customer, partners can also affect the service business model and influence all dimensions. On the one hand, the provider can request help from partners, on the other hand the provider can offer a platform for his partners to distribute own services and products. In this case the service provider holds an infrastructure that can be used by partners to access customers. An example of this kind of business model is Apple Inc., which is selling devices with access to an app store where partners are able to offer products to their customers. Therefore the main differences between partners and customers can be found in the elements Value Proposition, Customer Relationship and Channel, where partner support the provision of the service. The influence of the partners of the business model is shown in a table 2. Element Cost Structure Key Resources Key Activities Value Proposition Customer Relationship Channel Revenue Streams Partner perspective –Evidence of co-creation in business model elements • • • • • • • • Cost incurred / borne by partners Partner providing resources Mutual influence on resource selection and use Joint activities Partner enhances co-creation of provider and vice versa Provider opens customer relationship to partners and vice versa Partner opens channels to customers for partners and vice versa Shared monetary benefits / revenue Table 2: Partner perspective –Evidence of co-creation in business model elements 4 Conclusion and Outlook The paper shows how an adaptation of Osterwalder´s business model canvas can be utilized to take co-creation into account of business modeling, which is a main shortcoming of recent business model approaches. Hence, the adapted model gives a framework that is eligible to model service businesses, because one of the main characteristics of them is supported considering customers as well as partners. This allows representing a deep integration of the customers and partners in the value creation. According to the understanding of business implied by service dominant logic this is a critical aspect and is not applied in recent business model approaches. Furthermore with the adapted model it is possible to analyze, describe and evolve business models with emphasis on services. As this paper represents research-in-progress the described solution cannot be seen as a complete solution for all paucities of recent business model approaches, but it gives an implication how to deal with service specifics in the context of business modeling. The next step on the research agenda addresses a refinement of the business model canvas according to service-dominant logic. Further, a meta model for the service business model will be abstracted. Beyond this it will be necessary to prove the adaptation by specific examples in order to evaluate the adapted business model canvas. 247 References [Al10] Al-Debei, M.: The design and engineering of innovative mobile data services: An ontological Framework founded on business model thinking. Brunel University, 2010. [CS06] Chesbrough, H.; Spohrer, J.: A research manifesto for services science. In: Communications of the ACM, 49, 7, 2006; pp. 35-40. [ETG10] Edvardsson, B.; Tronvoll, B.; Gruber, T.: Expanding understanding of service exchange and value co-creation: a social construction approach. In: Journal of the Academy of Marketing Science, 37, 2, 2010; pp. 327–339. [GKW11]Gustafsson, A.; Kristensson, P.; Witell, L.: The Dimensions of Co-Creation and its Contribution to Market Success. In (Rhee, B. van der; Victorino, L. Eds.): Proc. 12th Int. Reseach Symposium on Service Excellence in Management, Ithaca, New York, 2011, Cayuga Press, Ithaca, New York, 2011; pp. 494-503. [Gr08] Grönroos, C.: Service logic revisited: who creates value? And who co-creates? In: European Business Review 20, 4, 2008; pp. 298-314. [GR11] Grönroos, C.; Ravald, A.: Service as business logic: implications for value creation and marketing. In: Journal of Service Management, 22, 1, 2011; pp. 5-22. [KMJ08] Kristensson, P.; Matthing, J.; Johansson, N.: Key strategies for the successful involvement of customers in the co-creation of new technology-based services. In: International Journal of Service Industry Management, 19, 4, 2008; pp. 474-491. [Ne08] Neely, A.: Exploring the financial consequences of the servitization of manufacturing. In: Operations Management Research, 1, 2, 2008; pp.103-118. [OP10] Osterwalder, A.; Pigneur, Y.: Business Model Generation. John Wiley & Sons, Hoboken, 2010. [OPT05] Osterwalder, A.; Pigneur, Y; Tucci, C.: Clarifying Business Models: Origins, Present and Future of the Concept. In: Communications of the Association for Information Systems, 16, 1, 2005; pp. 1-25. [PR04] Prahalad, C K; Ramaswamy, Venkat: Co-creating unique value with customers. In: Strategy & Leadership, 32, 3, 2004; pp. 4-9. [Sp08] Spohrer, J. et al.: The Service System is the Basic Abstraction of Service Science. In: Proc. 41st Hawaii Int. Conf. on System Science, Big Island, 2008; pp. 104-114. [VL06] Vargo, S.; Lusch, R.: Service-Dominant Logic: What It Is, What It Is Not, What It Might Be. In (Vargo, S.; Lusch, R. eds.): The Service-Dominant Logic of Marketing: Dialog, Debate, and Directions, M.E. Sharpe, Armont, New York, 2006; pp. 43-56. [ZB10] Zolnowski, A.; Böhmann, T.: Stand und Perspektiven der Modellierung von Geschäftsmodellen aus Sicht des Dienstleistungsmanagements. Proceedings des Workshops Dienstleistungsmodellierung, In (Thomas, O.; Nüttgens, M. eds.): Dienstleistungsmodellierung. Heidelberg Physica, 2010; pp. 25-39. [ZB11] Zolnowski, A.; Böhmann, T.: Business modelling for services – Current state and research perspectives. In: AMCIS 2011 Proceedings – All Submissions. Paper 394, 2011. 248 GI-Edition Lecture Notes in Informatics P-1 P-2 P-3 P-4 P-5 P-6 P-7 P-8 P-9 P-10 P-11 P-12 P-13 P-14 P-15 P-16 P-17 Gregor Engels, Andreas Oberweis, Albert Zündorf (Hrsg.): Modellierung 2001. Mikhail Godlevsky, Heinrich C. Mayr (Hrsg.): Information Systems Technology and its Applications, ISTA’2001. Ana M. Moreno, Reind P. van de Riet (Hrsg.): Applications of Natural Lan-guage to Information Systems, NLDB’2001. H. Wörn, J. Mühling, C. Vahl, H.-P. Meinzer (Hrsg.): Rechner- und sensorgestützte Chirurgie; Workshop des SFB 414. Andy Schürr (Hg.): OMER – ObjectOriented Modeling of Embedded RealTime Systems. Hans-Jürgen Appelrath, Rolf Beyer, Uwe Marquardt, Heinrich C. Mayr, Claudia Steinberger (Hrsg.): Unternehmen Hochschule, UH’2001. Andy Evans, Robert France, Ana Moreira, Bernhard Rumpe (Hrsg.): Practical UMLBased Rigorous Development Methods – Countering or Integrating the extremists, pUML’2001. Reinhard Keil-Slawik, Johannes Magenheim (Hrsg.): Informatikunterricht und Medienbildung, INFOS’2001. Jan von Knop, Wilhelm Haverkamp (Hrsg.): Innovative Anwendungen in Kommunikationsnetzen, 15. DFN Arbeitstagung. Mirjam Minor, Steffen Staab (Hrsg.): 1st German Workshop on Experience Management: Sharing Experiences about the Sharing Experience. Michael Weber, Frank Kargl (Hrsg.): Mobile Ad-Hoc Netzwerke, WMAN 2002. Martin Glinz, Günther Müller-Luschnat (Hrsg.): Modellierung 2002. Jan von Knop, Peter Schirmbacher and Viljan Mahni_ (Hrsg.): The Changing Universities – The Role of Technology. Robert Tolksdorf, Rainer Eckstein (Hrsg.): XML-Technologien für das Semantic Web – XSW 2002. Hans-Bernd Bludau, Andreas Koop (Hrsg.): Mobile Computing in Medicine. J. Felix Hampe, Gerhard Schwabe (Hrsg.): Mobile and Collaborative Business 2002. Jan von Knop, Wilhelm Haverkamp (Hrsg.): Zukunft der Netze –Die Verletzbarkeit meistern, 16. DFN Arbeitstagung. P-18 P-19 P-20 P-21 P-22 P-23 P-24 P-25 P-26 P-27 P-28 P-29 P-30 P-31 Elmar J. Sinz, Markus Plaha (Hrsg.): Modellierung betrieblicher Informationssysteme – MobIS 2002. Sigrid Schubert, Bernd Reusch, Norbert Jesse (Hrsg.): Informatik bewegt – Informatik 2002 – 32. Jahrestagung der Gesellschaft für Informatik e.V. (GI) 30.Sept.-3. Okt. 2002 in Dortmund. Sigrid Schubert, Bernd Reusch, Norbert Jesse (Hrsg.): Informatik bewegt – Informatik 2002 – 32. Jahrestagung der Gesellschaft für Informatik e.V. (GI) 30.Sept.-3. Okt. 2002 in Dortmund (Ergänzungsband). Jörg Desel, Mathias Weske (Hrsg.): Promise 2002: Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen. Sigrid Schubert, Johannes Magenheim, Peter Hubwieser, Torsten Brinda (Hrsg.): Forschungsbeiträge zur “Didaktik der Informatik” – Theorie, Praxis, Evaluation. Thorsten Spitta, Jens Borchers, Harry M. Sneed (Hrsg.): Software Management 2002 – Fortschritt durch Beständigkeit Rainer Eckstein, Robert Tolksdorf (Hrsg.): XMIDX 2003 – XMLTechnologien für Middleware – Middleware für XML-Anwendungen Key Pousttchi, Klaus Turowski (Hrsg.): Mobile Commerce – Anwendungen und Perspektiven – 3. Workshop Mobile Commerce, Universität Augsburg, 04.02.2003 Gerhard Weikum, Harald Schöning, Erhard Rahm (Hrsg.): BTW 2003: Datenbanksysteme für Business, Technologie und Web Michael Kroll, Hans-Gerd Lipinski, Kay Melzer (Hrsg.): Mobiles Computing in der Medizin Ulrich Reimer, Andreas Abecker, Steffen Staab, Gerd Stumme (Hrsg.): WM 2003: Professionelles Wissensmanagement – Er-fahrungen und Visionen Antje Düsterhöft, Bernhard Thalheim (Eds.): NLDB’2003: Natural Language Processing and Information Systems Mikhail Godlevsky, Stephen Liddle, Heinrich C. Mayr (Eds.): Information Systems Technology and its Applications Arslan Brömme, Christoph Busch (Eds.): BIOSIG 2003: Biometrics and Electronic Signatures P-32 P-33 P-34 P-35 P-36 P-37 P-38 P-39 P-40 P-41 P-42 P-43 P-44 P-45 P-46 P-47 Peter Hubwieser (Hrsg.): Informatische Fachkonzepte im Unterricht – INFOS 2003 Andreas Geyer-Schulz, Alfred Taudes (Hrsg.): Informationswirtschaft: Ein Sektor mit Zukunft Klaus Dittrich, Wolfgang König, Andreas Oberweis, Kai Rannenberg, Wolfgang Wahlster (Hrsg.): Informatik 2003 – Innovative Informatikanwendungen (Band 1) Klaus Dittrich, Wolfgang König, Andreas Oberweis, Kai Rannenberg, Wolfgang Wahlster (Hrsg.): Informatik 2003 – Innovative Informatikanwendungen (Band 2) Rüdiger Grimm, Hubert B. Keller, Kai Rannenberg (Hrsg.): Informatik 2003 – Mit Sicherheit Informatik Arndt Bode, Jörg Desel, Sabine Rathmayer, Martin Wessner (Hrsg.): DeLFI 2003: e-Learning Fachtagung Informatik E.J. Sinz, M. Plaha, P. Neckel (Hrsg.): Modellierung betrieblicher Informationssysteme – MobIS 2003 Jens Nedon, Sandra Frings, Oliver Göbel (Hrsg.): IT-Incident Management & ITForensics – IMF 2003 Michael Rebstock (Hrsg.): Modellierung betrieblicher Informationssysteme – MobIS 2004 Uwe Brinkschulte, Jürgen Becker, Dietmar Fey, Karl-Erwin Großpietsch, Christian Hochberger, Erik Maehle, Thomas Runkler (Edts.): ARCS 2004 – Organic and Pervasive Computing Key Pousttchi, Klaus Turowski (Hrsg.): Mobile Economy – Transaktionen und Prozesse, Anwendungen und Dienste Birgitta König-Ries, Michael Klein, Philipp Obreiter (Hrsg.): Persistance, Scalability, Transactions – Database Mechanisms for Mobile Applications Jan von Knop, Wilhelm Haverkamp, Eike Jessen (Hrsg.): Security, E-Learning. E-Services Bernhard Rumpe, Wofgang Hesse (Hrsg.): Modellierung 2004 Ulrich Flegel, Michael Meier (Hrsg.): Detection of Intrusions of Malware & Vulnerability Assessment Alexander Prosser, Robert Krimmer (Hrsg.): Electronic Voting in Europe – Technology, Law, Politics and Society P-48 P-49 P-50 P-51 P-52 P-53 P-54 P-55 P-56 P-57 P-58 P-59 P-60 P-61 P-62 P-63 Anatoly Doroshenko, Terry Halpin, Stephen W. Liddle, Heinrich C. Mayr (Hrsg.): Information Systems Technology and its Applications G. Schiefer, P. Wagner, M. Morgenstern, U. Rickert (Hrsg.): Integration und Datensicherheit – Anforderungen, Konflikte und Perspektiven Peter Dadam, Manfred Reichert (Hrsg.): INFORMATIK 2004 – Informatik verbindet (Band 1) Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 20.-24. September 2004 in Ulm Peter Dadam, Manfred Reichert (Hrsg.): INFORMATIK 2004 – Informatik verbindet (Band 2) Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 20.-24. September 2004 in Ulm Gregor Engels, Silke Seehusen (Hrsg.): DELFI 2004 – Tagungsband der 2. e-Learning Fachtagung Informatik Robert Giegerich, Jens Stoye (Hrsg.): German Conference on Bioinformatics – GCB 2004 Jens Borchers, Ralf Kneuper (Hrsg.): Softwaremanagement 2004 – Outsourcing und Integration Jan von Knop, Wilhelm Haverkamp, Eike Jessen (Hrsg.): E-Science und Grid Adhoc-Netze Medienintegration Fernand Feltz, Andreas Oberweis, Benoit Otjacques (Hrsg.): EMISA 2004 – Informationssysteme im E-Business und E-Government Klaus Turowski (Hrsg.): Architekturen, Komponenten, Anwendungen Sami Beydeda, Volker Gruhn, Johannes Mayer, Ralf Reussner, Franz Schweiggert (Hrsg.): Testing of Component-Based Systems and Software Quality J. Felix Hampe, Franz Lehner, Key Pousttchi, Kai Ranneberg, Klaus Turowski (Hrsg.): Mobile Business – Processes, Platforms, Payments Steffen Friedrich (Hrsg.): Unterrichtskonzepte für inforrmatische Bildung Paul Müller, Reinhard Gotzhein, Jens B. Schmitt (Hrsg.): Kommunikation in verteilten Systemen Federrath, Hannes (Hrsg.): „Sicherheit 2005“ – Sicherheit – Schutz und Zuverlässigkeit Roland Kaschek, Heinrich C. Mayr, Stephen Liddle (Hrsg.): Information Systems – Technology and ist Applications P-64 P-65 P-66 P-67 P-68 P-69 P-70 P-71 P-72 P-73 P-74 P-75 P-76 P-77 P-78 P-79 Peter Liggesmeyer, Klaus Pohl, Michael Goedicke (Hrsg.): Software Engineering 2005 Gottfried Vossen, Frank Leymann, Peter Lockemann, Wolffried Stucky (Hrsg.): Datenbanksysteme in Business, Technologie und Web Jörg M. Haake, Ulrike Lucke, Djamshid Tavangarian (Hrsg.): DeLFI 2005: 3. deutsche e-Learning Fachtagung Informatik Armin B. Cremers, Rainer Manthey, Peter Martini, Volker Steinhage (Hrsg.): INFORMATIK 2005 – Informatik LIVE (Band 1) Armin B. Cremers, Rainer Manthey, Peter Martini, Volker Steinhage (Hrsg.): INFORMATIK 2005 – Informatik LIVE (Band 2) Robert Hirschfeld, Ryszard Kowalcyk, Andreas Polze, Matthias Weske (Hrsg.): NODe 2005, GSEM 2005 Klaus Turowski, Johannes-Maria Zaha (Hrsg.): Component-oriented Enterprise Application (COAE 2005) Andrew Torda, Stefan Kurz, Matthias Rarey (Hrsg.): German Conference on Bioinformatics 2005 Klaus P. Jantke, Klaus-Peter Fähnrich, Wolfgang S. Wittig (Hrsg.): Marktplatz Internet: Von e-Learning bis e-Payment Jan von Knop, Wilhelm Haverkamp, Eike Jessen (Hrsg.): “Heute schon das Morgen sehen“ Christopher Wolf, Stefan Lucks, Po-Wah Yau (Hrsg.): WEWoRC 2005 – Western European Workshop on Research in Cryptology Jörg Desel, Ulrich Frank (Hrsg.): Enterprise Modelling and Information Systems Architecture Thomas Kirste, Birgitta König-Riess, Key Pousttchi, Klaus Turowski (Hrsg.): Mobile Informationssysteme – Potentiale, Hindernisse, Einsatz Jana Dittmann (Hrsg.): SICHERHEIT 2006 K.-O. Wenkel, P. Wagner, M. Morgenstern, K. Luzi, P. Eisermann (Hrsg.): Landund Ernährungswirtschaft im Wandel Bettina Biel, Matthias Book, Volker Gruhn (Hrsg.): Softwareengineering 2006 P-80 P-81 P-82 P-83 P-84 P-85 P-86 P-87 P-88 P-90 P-91 P-92 P-93 P-94 P-95 P-96 P-97 Mareike Schoop, Christian Huemer, Michael Rebstock, Martin Bichler (Hrsg.): Service-Oriented Electronic Commerce Wolfgang Karl, Jürgen Becker, KarlErwin Großpietsch, Christian Hochberger, Erik Maehle (Hrsg.): ARCS´06 Heinrich C. Mayr, Ruth Breu (Hrsg.): Modellierung 2006 Daniel Huson, Oliver Kohlbacher, Andrei Lupas, Kay Nieselt and Andreas Zell (eds.): German Conference on Bioinformatics Dimitris Karagiannis, Heinrich C. Mayr, (Hrsg.): Information Systems Technology and its Applications Witold Abramowicz, Heinrich C. Mayr, (Hrsg.): Business Information Systems Robert Krimmer (Ed.): Electronic Voting 2006 Max Mühlhäuser, Guido Rößling, Ralf Steinmetz (Hrsg.): DELFI 2006: 4. e-Learning Fachtagung Informatik Robert Hirschfeld, Andreas Polze, Ryszard Kowalczyk (Hrsg.): NODe 2006, GSEM 2006 Joachim Schelp, Robert Winter, Ulrich Frank, Bodo Rieger, Klaus Turowski (Hrsg.): Integration, Informationslogistik und Architektur Henrik Stormer, Andreas Meier, Michael Schumacher (Eds.): European Conference on eHealth 2006 Fernand Feltz, Benoît Otjacques, Andreas Oberweis, Nicolas Poussing (Eds.): AIM 2006 Christian Hochberger, Rüdiger Liskowsky (Eds.): INFORMATIK 2006 – Informatik für Menschen, Band 1 Christian Hochberger, Rüdiger Liskowsky (Eds.): INFORMATIK 2006 – Informatik für Menschen, Band 2 Matthias Weske, Markus Nüttgens (Eds.): EMISA 2005: Methoden, Konzepte und Technologien für die Entwicklung von dienstbasierten Informationssystemen Saartje Brockmans, Jürgen Jung, York Sure (Eds.): Meta-Modelling and Ontologies Oliver Göbel, Dirk Schadt, Sandra Frings, Hardo Hase, Detlef Günther, Jens Nedon (Eds.): IT-Incident Mangament & ITForensics – IMF 2006 P-98 P-99 P-100 P-101 P-102 P-103 P-104 P-105 P-106 P-107 P-108 P-109 P-110 P-111 Hans Brandt-Pook, Werner Simonsmeier und Thorsten Spitta (Hrsg.): Beratung in der Softwareentwicklung – Modelle, Methoden, Best Practices Andreas Schwill, Carsten Schulte, Marco Thomas (Hrsg.): Didaktik der Informatik Peter Forbrig, Günter Siegel, Markus Schneider (Hrsg.): HDI 2006: Hochschuldidaktik der Informatik Stefan Böttinger, Ludwig Theuvsen, Susanne Rank, Marlies Morgenstern (Hrsg.): Agrarinformatik im Spannungsfeld zwischen Regionalisierung und globalen Wertschöpfungsketten Otto Spaniol (Eds.): Mobile Services and Personalized Environments Alfons Kemper, Harald Schöning, Thomas Rose, Matthias Jarke, Thomas Seidl, Christoph Quix, Christoph Brochhaus (Hrsg.): Datenbanksysteme in Business, Technologie und Web (BTW 2007) Birgitta König-Ries, Franz Lehner, Rainer Malaka, Can Türker (Hrsg.) MMS 2007: Mobilität und mobile Informationssysteme Wolf-Gideon Bleek, Jörg Raasch, Heinz Züllighoven (Hrsg.) Software Engineering 2007 Wolf-Gideon Bleek, Henning Schwentner, Heinz Züllighoven (Hrsg.) Software Engineering 2007 – Beiträge zu den Workshops Heinrich C. Mayr, Dimitris Karagiannis (eds.) Information Systems Technology and its Applications Arslan Brömme, Christoph Busch, Detlef Hühnlein (eds.) BIOSIG 2007: Biometrics and Electronic Signatures Rainer Koschke, Otthein Herzog, KarlHeinz Rödiger, Marc Ronthaler (Hrsg.) INFORMATIK 2007 Informatik trifft Logistik Band 1 Rainer Koschke, Otthein Herzog, KarlHeinz Rödiger, Marc Ronthaler (Hrsg.) INFORMATIK 2007 Informatik trifft Logistik Band 2 Christian Eibl, Johannes Magenheim, Sigrid Schubert, Martin Wessner (Hrsg.) DeLFI 2007: 5. e-Learning Fachtagung Informatik P-112 P-113 P-114 P-115 P-116 P-117 P-118 P-119 P-120 P-121 P-122 Sigrid Schubert (Hrsg.) Didaktik der Informatik in Theorie und Praxis Sören Auer, Christian Bizer, Claudia Müller, Anna V. Zhdanova (Eds.) The Social Semantic Web 2007 Proceedings of the 1st Conference on Social Semantic Web (CSSW) Sandra Frings, Oliver Göbel, Detlef Günther, Hardo G. Hase, Jens Nedon, Dirk Schadt, Arslan Brömme (Eds.) IMF2007 IT-incident management & IT-forensics Proceedings of the 3rd International Conference on IT-Incident Management & IT-Forensics Claudia Falter, Alexander Schliep, Joachim Selbig, Martin Vingron and Dirk Walther (Eds.) German conference on bioinformatics GCB 2007 Witold Abramowicz, Leszek Maciszek (Eds.) Business Process and Services Computing 1st International Working Conference on Business Process and Services Computing BPSC 2007 Ryszard Kowalczyk (Ed.) Grid service engineering and manegement The 4th International Conference on Grid Service Engineering and Management GSEM 2007 Andreas Hein, Wilfried Thoben, HansJürgen Appelrath, Peter Jensch (Eds.) European Conference on ehealth 2007 Manfred Reichert, Stefan Strecker, Klaus Turowski (Eds.) Enterprise Modelling and Information Systems Architectures Concepts and Applications Adam Pawlak, Kurt Sandkuhl, Wojciech Cholewa, Leandro Soares Indrusiak (Eds.) Coordination of Collaborative Engineering - State of the Art and Future Challenges Korbinian Herrmann, Bernd Bruegge (Hrsg.) Software Engineering 2008 Fachtagung des GI-Fachbereichs Softwaretechnik Walid Maalej, Bernd Bruegge (Hrsg.) Software Engineering 2008 Workshopband Fachtagung des GI-Fachbereichs Softwaretechnik P-123 P-124 P-125 P-126 P-127 P-128 P-129 P-130 P-131 P-132 Michael H. Breitner, Martin Breunig, Elgar Fleisch, Ley Pousttchi, Klaus Turowski (Hrsg.) Mobile und Ubiquitäre Informationssysteme – Technologien, Prozesse, Marktfähigkeit Proceedings zur 3. Konferenz Mobile und Ubiquitäre Informationssysteme (MMS 2008) Wolfgang E. Nagel, Rolf Hoffmann, Andreas Koch (Eds.) 9th Workshop on Parallel Systems and Algorithms (PASA) Workshop of the GI/ITG Speciel Interest Groups PARS and PARVA Rolf A.E. Müller, Hans-H. Sundermeier, Ludwig Theuvsen, Stephanie Schütze, Marlies Morgenstern (Hrsg.) Unternehmens-IT: Führungsinstrument oder Verwaltungsbürde Referate der 28. GIL Jahrestagung Rainer Gimnich, Uwe Kaiser, Jochen Quante, Andreas Winter (Hrsg.) 10th Workshop Software Reengineering (WSR 2008) Thomas Kühne, Wolfgang Reisig, Friedrich Steimann (Hrsg.) Modellierung 2008 Ammar Alkassar, Jörg Siekmann (Hrsg.) Sicherheit 2008 Sicherheit, Schutz und Zuverlässigkeit Beiträge der 4. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.V. (GI) 2.-4. April 2008 Saarbrücken, Germany Wolfgang Hesse, Andreas Oberweis (Eds.) Sigsand-Europe 2008 Proceedings of the Third AIS SIGSAND European Symposium on Analysis, Design, Use and Societal Impact of Information Systems Paul Müller, Bernhard Neumair, Gabi Dreo Rodosek (Hrsg.) 1. DFN-Forum Kommunikationstechnologien Beiträge der Fachtagung Robert Krimmer, Rüdiger Grimm (Eds.) 3rd International Conference on Electronic Voting 2008 Co-organized by Council of Europe, Gesellschaft für Informatik and E-Voting. CC Silke Seehusen, Ulrike Lucke, Stefan Fischer (Hrsg.) DeLFI 2008: Die 6. e-Learning Fachtagung Informatik P-133 P-134 P-135 P-136 P-137 P-138 P-139 P-140 P-141 P-142 P-143 Heinz-Gerd Hegering, Axel Lehmann, Hans Jürgen Ohlbach, Christian Scheideler (Hrsg.) INFORMATIK 2008 Beherrschbare Systeme – dank Informatik Band 1 Heinz-Gerd Hegering, Axel Lehmann, Hans Jürgen Ohlbach, Christian Scheideler (Hrsg.) INFORMATIK 2008 Beherrschbare Systeme – dank Informatik Band 2 Torsten Brinda, Michael Fothe, Peter Hubwieser, Kirsten Schlüter (Hrsg.) Didaktik der Informatik – Aktuelle Forschungsergebnisse Andreas Beyer, Michael Schroeder (Eds.) German Conference on Bioinformatics GCB 2008 Arslan Brömme, Christoph Busch, Detlef Hühnlein (Eds.) BIOSIG 2008: Biometrics and Electronic Signatures Barbara Dinter, Robert Winter, Peter Chamoni, Norbert Gronau, Klaus Turowski (Hrsg.) Synergien durch Integration und Informationslogistik Proceedings zur DW2008 Georg Herzwurm, Martin Mikusz (Hrsg.) Industrialisierung des SoftwareManagements Fachtagung des GI-Fachausschusses Management der Anwendungsentwicklung und -wartung im Fachbereich Wirtschaftsinformatik Oliver Göbel, Sandra Frings, Detlef Günther, Jens Nedon, Dirk Schadt (Eds.) IMF 2008 - IT Incident Management & IT Forensics Peter Loos, Markus Nüttgens, Klaus Turowski, Dirk Werth (Hrsg.) Modellierung betrieblicher Informationssysteme (MobIS 2008) Modellierung zwischen SOA und Compliance Management R. Bill, P. Korduan, L. Theuvsen, M. Morgenstern (Hrsg.) Anforderungen an die Agrarinformatik durch Globalisierung und Klimaveränderung Peter Liggesmeyer, Gregor Engels, Jürgen Münch, Jörg Dörr, Norman Riegel (Hrsg.) Software Engineering 2009 Fachtagung des GI-Fachbereichs Softwaretechnik P-144 P-145 P-146 P-147 P-148 P-149 P-150 P-151 P-152 P-153 P-154 Johann-Christoph Freytag, Thomas Ruf, Wolfgang Lehner, Gottfried Vossen (Hrsg.) Datenbanksysteme in Business, Technologie und Web (BTW) Knut Hinkelmann, Holger Wache (Eds.) WM2009: 5th Conference on Professional Knowledge Management Markus Bick, Martin Breunig, Hagen Höpfner (Hrsg.) Mobile und Ubiquitäre Informationssysteme – Entwicklung, Implementierung und Anwendung 4. Konferenz Mobile und Ubiquitäre Informationssysteme (MMS 2009) Witold Abramowicz, Leszek Maciaszek, Ryszard Kowalczyk, Andreas Speck (Eds.) Business Process, Services Computing and Intelligent Service Management BPSC 2009 · ISM 2009 · YRW-MBP 2009 Christian Erfurth, Gerald Eichler, Volkmar Schau (Eds.) 9th International Conference on Innovative Internet Community Systems I2CS 2009 Paul Müller, Bernhard Neumair, Gabi Dreo Rodosek (Hrsg.) 2. DFN-Forum Kommunikationstechnologien Beiträge der Fachtagung Jürgen Münch, Peter Liggesmeyer (Hrsg.) Software Engineering 2009 - Workshopband Armin Heinzl, Peter Dadam, Stefan Kirn, Peter Lockemann (Eds.) PRIMIUM Process Innovation for Enterprise Software Jan Mendling, Stefanie Rinderle-Ma, Werner Esswein (Eds.) Enterprise Modelling and Information Systems Architectures Proceedings of the 3rd Int‘l Workshop EMISA 2009 Andreas Schwill, Nicolas Apostolopoulos (Hrsg.) Lernen im Digitalen Zeitalter DeLFI 2009 – Die 7. E-Learning Fachtagung Informatik Stefan Fischer, Erik Maehle Rüdiger Reischuk (Hrsg.) INFORMATIK 2009 Im Focus das Leben P-155 P-156 P-157 P-158 P-159 P-160 P-161 P-162 P-163 P-164 Arslan Brömme, Christoph Busch, Detlef Hühnlein (Eds.) BIOSIG 2009: Biometrics and Electronic Signatures Proceedings of the Special Interest Group on Biometrics and Electronic Signatures Bernhard Koerber (Hrsg.) Zukunft braucht Herkunft 25 Jahre »INFOS – Informatik und Schule« Ivo Grosse, Steffen Neumann, Stefan Posch, Falk Schreiber, Peter Stadler (Eds.) German Conference on Bioinformatics 2009 W. Claupein, L. Theuvsen, A. Kämpf, M. Morgenstern (Hrsg.) Precision Agriculture Reloaded – Informationsgestützte Landwirtschaft Gregor Engels, Markus Luckey, Wilhelm Schäfer (Hrsg.) Software Engineering 2010 Gregor Engels, Markus Luckey, Alexander Pretschner, Ralf Reussner (Hrsg.) Software Engineering 2010 – Workshopband (inkl. Doktorandensymposium) Gregor Engels, Dimitris Karagiannis Heinrich C. Mayr (Hrsg.) Modellierung 2010 Maria A. Wimmer, Uwe Brinkhoff, Siegfried Kaiser, Dagmar LückSchneider, Erich Schweighofer, Andreas Wiebe (Hrsg.) Vernetzte IT für einen effektiven Staat Gemeinsame Fachtagung Verwaltungsinformatik (FTVI) und Fachtagung Rechtsinformatik (FTRI) 2010 Markus Bick, Stefan Eulgem, Elgar Fleisch, J. Felix Hampe, Birgitta König-Ries, Franz Lehner, Key Pousttchi, Kai Rannenberg (Hrsg.) Mobile und Ubiquitäre Informationssysteme Technologien, Anwendungen und Dienste zur Unterstützung von mobiler Kollaboration Arslan Brömme, Christoph Busch (Eds.) BIOSIG 2010: Biometrics and Electronic Signatures Proceedings of the Special Interest Group on Biometrics and Electronic Signatures P-165 P-166 P-167 P-168 P-169 P-170 P-171 P-172 P-173 P-174 Gerald Eichler, Peter Kropf, Ulrike Lechner, Phayung Meesad, Herwig Unger (Eds.) 10th International Conference on Innovative Internet Community Systems (I2CS) – Jubilee Edition 2010 – Paul Müller, Bernhard Neumair, Gabi Dreo Rodosek (Hrsg.) 3. DFN-Forum Kommunikationstechnologien Beiträge der Fachtagung Robert Krimmer, Rüdiger Grimm (Eds.) 4th International Conference on Electronic Voting 2010 co-organized by the Council of Europe, Gesellschaft für Informatik and E-Voting.CC Ira Diethelm, Christina Dörge, Claudia Hildebrandt, Carsten Schulte (Hrsg.) Didaktik der Informatik Möglichkeiten empirischer Forschungsmethoden und Perspektiven der Fachdidaktik Michael Kerres, Nadine Ojstersek Ulrik Schroeder, Ulrich Hoppe (Hrsg.) DeLFI 2010 - 8. Tagung der Fachgruppe E-Learning der Gesellschaft für Informatik e.V. Felix C. Freiling (Hrsg.) Sicherheit 2010 Sicherheit, Schutz und Zuverlässigkeit Werner Esswein, Klaus Turowski, Martin Juhrisch (Hrsg.) Modellierung betrieblicher Informationssysteme (MobIS 2010) Modellgestütztes Management Stefan Klink, Agnes Koschmider Marco Mevius, Andreas Oberweis (Hrsg.) EMISA 2010 Einflussfaktoren auf die Entwicklung flexibler, integrierter Informationssysteme Beiträge des Workshops der GI-Fachgruppe EMISA (Entwicklungsmethoden für Informationssysteme und deren Anwendung) Dietmar Schomburg, Andreas Grote (Eds.) German Conference on Bioinformatics 2010 Arslan Brömme, Torsten Eymann, Detlef Hühnlein, Heiko Roßnagel, Paul Schmücker (Hrsg.) perspeGKtive 2010 Workshop „Innovative und sichere Informationstechnologie für das Gesundheitswesen von morgen“ P-175 P-176 P-177 P-178 P-179 P-180 P-181 P-182 P-183 P-184 Klaus-Peter Fähnrich, Bogdan Franczyk (Hrsg.) INFORMATIK 2010 Service Science – Neue Perspektiven für die Informatik Band 1 Klaus-Peter Fähnrich, Bogdan Franczyk (Hrsg.) INFORMATIK 2010 Service Science – Neue Perspektiven für die Informatik Band 2 Witold Abramowicz, Rainer Alt, Klaus-Peter Fähnrich, Bogdan Franczyk, Leszek A. Maciaszek (Eds.) INFORMATIK 2010 Business Process and Service Science – Proceedings of ISSS and BPSC Wolfram Pietsch, Benedikt Krams (Hrsg.) Vom Projekt zum Produkt Fachtagung des GIFachausschusses Management der Anwendungsentwicklung und -wartung im Fachbereich Wirtschafts-informatik (WI-MAW), Aachen, 2010 Stefan Gruner, Bernhard Rumpe (Eds.) FM+AM`2010 Second International Workshop on Formal Methods and Agile Methods Theo Härder, Wolfgang Lehner, Bernhard Mitschang, Harald Schöning, Holger Schwarz (Hrsg.) Datenbanksysteme für Business, Technologie und Web (BTW) 14. Fachtagung des GI-Fachbereichs „Datenbanken und Informationssysteme“ (DBIS) Michael Clasen, Otto Schätzel, Brigitte Theuvsen (Hrsg.) Qualität und Effizienz durch informationsgestützte Landwirtschaft, Fokus: Moderne Weinwirtschaft Ronald Maier (Hrsg.) 6th Conference on Professional Knowledge Management From Knowledge to Action Ralf Reussner, Matthias Grund, Andreas Oberweis, Walter Tichy (Hrsg.) Software Engineering 2011 Fachtagung des GI-Fachbereichs Softwaretechnik Ralf Reussner, Alexander Pretschner, Stefan Jähnichen (Hrsg.) Software Engineering 2011 Workshopband (inkl. Doktorandensymposium) P-185 P-186 P-187 P-188 P-189 P-190 Hagen Höpfner, Günther Specht, Thomas Ritz, Christian Bunse (Hrsg.) MMS 2011: Mobile und ubiquitäre Informationssysteme Proceedings zur 6. Konferenz Mobile und Ubiquitäre Informationssysteme (MMS 2011) Gerald Eichler, Axel Küpper, Volkmar Schau, Hacène Fouchal, Herwig Unger (Eds.) 11th International Conference on Innovative Internet Community Systems (I2CS) Paul Müller, Bernhard Neumair, Gabi Dreo Rodosek (Hrsg.) 4. DFN-Forum Kommunikationstechnologien, Beiträge der Fachtagung 20. Juni bis 21. Juni 2011 Bonn Holger Rohland, Andrea Kienle, Steffen Friedrich (Hrsg.) DeLFI 2011 – Die 9. e-Learning Fachtagung Informatik der Gesellschaft für Informatik e.V. 5.–8. September 2011, Dresden Thomas, Marco (Hrsg.) Informatik in Bildung und Beruf INFOS 2011 14. GI-Fachtagung Informatik und Schule Markus Nüttgens, Oliver Thomas, Barbara Weber (Eds.) Enterprise Modelling and Information Systems Architectures (EMISA 2011) The titles can be purchased at: Köllen Druck + Verlag GmbH Ernst-Robert-Curtius-Str. 14 · D-53117 Bonn Fax: +49 (0)228/9898222 E-Mail: druckverlag@koellen.de