3rd International Workshop on Semantic Business Process Management (SBPM 2008) 4th European Semantic Web Conference (ESWC 2008)

Martin Hepp, Nenad Stojanovic, Knut Hinkelmann, Dimitris Karagiannis, and Rüdiger Klein (Editors) Preliminary On-Site Proceedings of the 3rd Intern...
Author: Benjamin Quinn
2 downloads 0 Views 7MB Size
Martin Hepp, Nenad Stojanovic, Knut Hinkelmann, Dimitris Karagiannis, and Rüdiger Klein (Editors)

Preliminary On-Site

Proceedings of the

3rd International Workshop on Semantic Business Process Management (SBPM 2008) in conjunction with the

4th European Semantic Web Conference (ESWC 2008) Tenerife, Spain, June 2, 2008 Organizing Committee: Martin Hepp (Bundeswehr University Munich and STI Innsbruck) Nenad Stojanovic (FZI, University of Karlsruhe) Knut Hinkelmann (University of Applied Sciences Northwestern Switzerland) Dimitris Karagiannis (University of Vienna) Rüdiger Klein (Fraunhofer IPK)

Workshop URI: http://sbpm2008.fzi.de/ The official post-proceedings will be published in the CEUR Workshop Proceedings series, ISSN 1613-0073, available online at http://CEURWS.org/Vol-xxx/.

This page is intentionally left blank.

Table of Contents Part 1: Mining, Analysis, Compliance, and Validation 1. Ana Karla Alves de Medeiros, Alessio Carenini, Irene Celino, Emanuele Della Valle, Federico Michele Facca, Michael Oppitz, Gernot Zeissler, and Stefan Zöller: Using Semantics to Aid Scenario-Based Analysis

Full Paper

2. Marwane El Kharbili, Sebastian Stein, Ivan Markovic, and Elke Pulvermueller: Towards Policy-Powered Semantic Enterprise Compliance Management (Short Paper)

Short Paper

3. Ingo Weber, Joerg Hoffmann, and Jan Mendling: Semantic Business Process Validation (Full Paper)

Full Paper

Part 2: Knowledge Elicitation and Modeling 4. Daniela Feldkamp and Simon Nikles: GoMoKIT: Towards an applicable goal-oriented Business Process Modelling approach for Knowledge-Intensive Tasks (Short Paper)

Short Paper

5. Witold Abramowicz, Agata Filipowska Monika Kaczmarek, Carlos Pedrinaci, Monika Starzecka, and Adam Walczak: Organization Structure Description for the Needs of Semantic Business Process Management (Full Paper)

Full Paper

Part 3: Event-Handling and Attention Management 6. Darko Anicic, Nenad Stojanovic, and Dimitris Apostolou: Enterprise Attention Management System (Full Paper)

Full Paper

7. Kay-Uwe Schmidt, Darko Anicic, and Roland Stühmer: Eventdriven Reactivity: A Survey and Requirements Analysis (Full Paper)

Full Paper

Part 4: Various Topics 8. Ken Decreus, Frederik Gailly, and Geert Poels: A Toolkit For Business Process Owners to Capture Early System Requirements (Short Paper)

Short Paper

9. Sinan Sen and Slavko Tomcic: Contextualized Ontology-Based Similarity in the Human Resources Domain: A Business Use Case (Short Paper)

Short Paper

10. Paul Stynes, Owen Conlan, and D O'Sullivan: Towards a Simulation-based Communication Tool to Support Semantic Business Process Management (Short Paper)

Short Paper

11. Dimitris Karagiannis, Robert Woitsch, Wilfrid Utz, Hannes Eichner and Vedran Hrgovcic: The Business Process as an Integration Platform: Case Studies from the EU-Projects LD-Cast and BREIN (Short Paper)

Short Paper

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis Ana Karla Alves de Medeiros1 , Alessio Carenini2 , Irene Celino2 , Emanuele Della Valle2 , Federico M. Facca2 , Michael Oppitz3 , Gernot Zeissler3 , and Stefan Z¨oller3 1

TUE – Technische Universiteit Eindhoven, Postbus 513, 5600 MB, Eindhoven, NL [email protected] 2 CEFRIEL – Politecnico of Milano, Via Fucini 2, 20133 Milano, I [email protected] 3 IBIS Prof. Thome AG – Mergentheimer Str. 76a, 97082 Wuerzburg, D [email protected]

Abstract. Scenario-based analysis describes customer needs and focuses on different aspects of information systems. A scenario typically has several metrics which compute specific information about transaction data, organizational structures and configuration settings. The selection and configuration of metrics is not a trivial task and normally cannot be reused over different information systems. Therefore, this paper shows how semantics can aid this process. In fact, the proposed semantically aided analysis approach supports all the five phases of the scenario-based analysis process: (i) selection of metrics relevant to a given scenario, (ii) their configuration and (iii) execution, (iv) evaluation of returned results and (v) reporting of results. Our approach is illustrated by applying it to Reverse Business Engineering, a tool for scenario-based analysis commonly used by commercial ERP systems. However, the proposed approach is general enough to also be applied to other analysis techniques.

1

Introduction

Currenlty most companies use information systems to support the execution of their business processes. Examples of such information systems are ERP, CRM or Workflow Management Systems. These information systems usually generate events while executing business processes [1] and these events can be recorded in so-called event logs. The competitive world we live in requires companies to adapt their processes in a faster pace. Therefore, continuous and insightful feedback on how business processes are actually being executed becomes essential. Additionally, laws like the Sarbanes-Oxley Act force companies to show their compliance to standards. In short, there is a need for good analysis tools that can provide feedback information about how business process are actually being executed based on the observed (or registered) behavior in event logs. Scenariobased analysis is a common technique to do so. Scenario-based analysis describes customer needs and focuses on different aspects within an information system. A scenario is constituted by a multiplicity of predefined business questions, which will provide specific information

Page 1

SBPM 2008 Proceedings

2

Authors Suppressed Due to Excessive Length

with respect to transaction data, master data, organisational structures, and configuration settings. A business question consists of a generic question and system-specific patterns. These patterns extract information from event logs. An example of a tool using scenario based analysis is Reverse Business Engineering tool [2]. From a conceptual point of view, business questions can be seen as metrics that are defined by business analysts. These metrics represent the information to be measured within a particular system and are evaluated according to the data the system is able to expose. A given given scenario typically contains a huge number of metrics and analysts usually need to be properly assisted while selecting relevant ones to a given analysis scenario and data domain. In a nutshell, once metrics have been defined, the main steps of a generic scenario-based analysis process are as follows: 1. Selection, by an analyst, of the interesting metrics according to specific analysis scenario; 2. Configuration of selected analysis metrics by providing proper parameters to restrict the results; 3. Execution of configured analysis metrics; 4. Evaluation of results, like data filtering and aggregation; 5. Reporting of results. This paper shows a framework where ontologies are used to facilitate scenariobased analysis. The idea of using semantics to improve the analysis of business processes is not new [3,4,5,6,7] but none of the existing works have focussed on using semantics to support the analysis from the selection of the metrics to its execution and reporting. In fact, most of the existing work uses ontologies to enhance the execution and re-use of metrics 4 . Therefore, this paper is the first one to show how to use ontology to provide for semantic scenario-based analysis. This approach is illustrated by showing our first prototype to perform semantic RBE. This prototype is being implemented within the European project SUPER [8]. As stated in [8], SUPER “aims at providing a semantic-based and context-aware framework, based on Semantic Web Services technology that acquires, organizes, shares and uses the knowledge embedded in business processes within existing IT systems and software, and within employees’ heads, in order to make companies more adaptive”. This semantic framework will also support the semantic analysis of business processes. The remainder of this paper is organized as follows. Section 2 motivates the use of semantics in analyzing data and introduces the approach defined in this work. Section 3 proposes a concrete scenario to apply this approach to Reverse Business Engineering analysis technique. Section 4 contains an overview of related work in the field of semantic process analysis, and Section 5 has the conclusions and future directions of our research. 4

See Section 4 for more details.

Page 2

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

2

3

Semantically-Aided Analysis

Scenario-based analysis is characterized by a complex process where each step as its own peculiarities. The first step in the process is the selection of the metrics that have to be evaluated in order to fulfill a certain analysis need. Selected metrics has then to be fed with input elements that represent its execution constraints; data returned from the execution of analysis metrics are again processed by evaluation metrics that perform other transformation to clean and filter results. Finally results returned by evaluation metrics are transformation into the correct visualization pattern. This workflow traditionally features a massive use of implicit knowledge in all of its steps, and this knowledge has to be provided by the user. We will now explain how adding semantics can improve these steps, and so the overall analysis process, by using explicit, formal and shared knowledge. In order to select the proper analysis function for a given domain scenario, analysts have to exploit any possible knowledge (usually implicit) linking the function with the analysis scenario. This knowledge, in current systems, derives from an extensive usage of the system and from studying the documentation that specifies which task is performed by each of the functions provided by the system and in which context each function can be performed. Formally defining analysis functions using semantic technologies enable to link explicitly and automatically a function to its execution context. Explicit links help analysts in the selection of functions to be executed according to a set of constraints posed by the data domain and analysis scenario. Semantics can support the selection in two ways: in one case the analyst may restrict the set of analysis metrics he may apply on the data, selecting a set of concepts he considers relevant for the analysis scenario; in the dual case, given a set of instance data, it is possible to trace back which metrics may be applied to such data, and the analysis scenario to which the obtained metrics belong. Once a metric has been successfully selected, it still just represents a relation between a set of input elements and the expected resulting products. To be execution such metric still need to be properly configured with the right input data. Semantics may provide a great support to automate this configuration step: it can filter data presents in the knowledge base to identify possible parameter instances; or it may support the analyst in the creation of the correct instance leveraging on the formalized data model of the metric inputs. Then, after the configuration, an analysis function is ready to be executed. Currently, the logic of a metric is described using a programming language, thus embedding the logic into a particular implementation choice; thus, every time a new function has to be executed, a programmer must code the corresponding business logic. Semantics can be adopted to explicitly express the logic of a analysis metric in a formal language, thus completely decoupling the logical part from the code that performs the execution. Moreover, in this way, the results of a function’s execution are directly expressed using the same ontological model adopted to described the input data. Thus, removing any need for grounding mechanism, to lift results from the code level to the data model level. In this way also the definition of complex functions is easier: the output of a function can

Page 3

SBPM 2008 Proceedings

4

Authors Suppressed Due to Excessive Length

be used to feed another select-configure-execute loop. In particular the selection of a possible following function can directly selected according to the output of the proceeding one. The final step in the analysis process is the visualization of the results: the user, according to the kind of data and the analysis context, selects the best way of visualizing the results. The same modeling principles used on the analysis functions to ease selection can also be used to suggest the best visualization strategy for a given context. Moreover, the linkage with concepts expressed in external ontologies eases the task of transforming the results into data directly suitable for existing visualization systems. The remainder of this section introduces and discusses our approach in more details. 2.1

The Analysis Ontology

As introduced in Section 1, our scenario-based analysis approach relies on the usage of semantic technologies. The overall idea is not bounded to any peculiar semantic framework; the only requirements is the support for definition not only of data models but also of rules/axioms. Although ontologies provide the basis for some forms of reasoning, ontologies by themselves do not support the range of knowledge-based services that are required to fulfill the complexity of the common analysis functions. For example, the model can be defined using OWL [9] and SWRL [10], a rule specification language for OWL, or WSML [11]. In this work we use the WSMO framework and its modelling language WSML, the choice is motivated by the fact that such framework natively supports the definition of axioms or rules and, besides, it is adopted in the SUPER project. The Web Service Modelling Language (WSML), offers a set of language variants for describing the elements of the Web Service Modelling Ontology (WSMO) that enable modelers to balance between expressiveness and tractability according to different knowledge representation paradigms. The conceptual syntax of WSML adopts a frame-like style. The information about classes, attributes, relations and their parameters, instances and their attribute values are specified in one large syntactic construct, instead of being divided in a number of atomic chunks. In the rest of the section we describe how adopting semantic technologies enables the support and provision of better automation for the whole analysis process. The key factor to enable the whole analysis process using semantic technologies is to provide a conceptual model that formalizes all of its relevant aspects and covers all of its fundamental steps. In particular, we devise an ontological model that comprises the two main aspects of the analysis process: the analysis metric to be applied on the data to generate intermediate results and evaluation templates to be applied on the intermediate results to generated final reports. The abstractions used to model the analysis metrics should support analyst for their categorization and selection, their configuration and their execution. While models of the evaluation templates should support the filtering of templates according to the used analysis metrics, the aggregation/filtering of results

Page 4

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

5

Analysis Ontology Extraction Metrics

Selection

Configuration

Evaluation Metrics

Execution

Evaluation

Reporting

Fig. 1. The proposed modeling stack and its relations with the scenario-based analysis process.

and their presentation. Figure 1 gives an overview of the modelling stack at the base of our approach. 2.2

Metrics for Data Extraction

To model analysis metrics, we have to keep into account the three fundamental goals we want to achieve: (i) an easy way to allow categorization and thus selection of metrics according to analyst needs and the considered scenario; (ii) enable assisted configuration of the required parameters for selected metrics, enabling, if needed, the assisted creation of complex parameters values; and, finally, (iii) a specification of how to compute the metrics, based on (i) and (ii) and on the model of the data under analysis. Given such objectives, the natural modelling abstraction that fits the categorization of metrics, is the use of a taxonomy. Thus, we formalize metrics as ontological concepts. In more details, we define a generic Metric concept that is described by a set of attributes. The attributes are defined over an ontology, thus enabling a fine grained categorization of metrics; e.g., an attribute may be linked to a concept Scenario, to allow metrics categorization according to an ontology of scenarios. Then, each peculiar metric is defined as sub concept of the generic Metric concept and its attributes are defined over sub concepts of the original attribute type; e.g., an attribute may be linked to a particular analysis scenario defined by a concept belonging to a branch of the same ontology used at the previous step. The choice of modeling metrics not as instances of the metric concept, is fundamental to allow the definition of sub-metrics using the inheritance mechanism provided by ontologies. In this way it is possible to define a well formalized ontology of metrics, where also the attribute ranges of metric concept belong to ontolgoies enabling efficient and powerful metrics categorization. This enables the analysts to easily select the most suitable metrics among a huge variety of them, by simply specifying a set of possible values for the range of their attributes (i.e. filtering them by the attributes values). At this stage of the modeling process there is still no need of any connection with the actual model of the data to be analysed. The modelling abstraction just introduced, while being perfect for the scope of classifying analysis metrics, is not suitable for the specification of the metrics

Page 5

SBPM 2008 Proceedings

6

Authors Suppressed Due to Excessive Length

themselves and their parameters. This aspect is crucial to enable the assisted configuration of metrics. For this scope we select as abstraction relations with arity n. Relations are used to define the metric and its possible parameters, i.e., each relation is a metric and its terms represent the parameters for the metric. Terms are constrained to a type range, thus specifying the expected input types for a given metric. The analyst configures the metrics by coupling the terms in the relation definition with the actual instances in the range of the terms type. Configured parameters (i.e. coupled terms) act as input parameters, while free parameters (i.e. not coupled terms) act as output parameters. Parameters may be defined in terms of the model of the data to be analysed (e.g. a given concept in the analysed data), or may be generic and not grounded to the actual data model (e.g. temporal constraints). Such modeling abstraction solves the problem of parameter definition and their expected order. Nevertheless, it decouples the parameter definition problem from the conceptualization used to the define the metric ontology. To preserve such important link in the model, we use a relation to link the metric concept with the definition of its relation. However, this is optional because metrics in the upper level of the ontology may not have any associated relation. In such cases, these metrics are abstract containers for a set of concrete metrics. The relation itself specifies how to configure the metric in order to enable its evaluation. It does not contain any information about the way the relation, and hence the metric evaluation results, are actually computed. To formalize such fundamental requirements that enable the metric execution, we use axioms. Axioms (or rules), are logical expression that define how a relation is actually computed, enabling its evaluation thanks to the support of a reasoning engine. In particular, logical expressions, given the parameters defined in the relation and the model of the analysed data, define how the terms of the relation instances, which represent the results of the metric execution, are correlated. 2.3

Metrics Applied over Results

The post processing of the analysis results includes calculation, data filtering/aggregation and data visualization. Post processing functions can be viewed as the dual of the analysis metrics and are formalized in a similar way. In particular, we define a generic Function concept that is described by a set of attributes. The attributes are defined over an ontology, thus enabling a fine grained categorization of functions. Among the attributes, it is possible to include the type of post processing function, and the analysis metrics to which the function may be applied. Then, each peculiar function is defined as sub concept of the generic Function concept and its attributes are defined over sub concepts of the original attribute type. In this way, we can define a well formalized ontology of post processing functions, that can be automatically selected according to the analysis metric used in the previous steps of the analysis process. The Function concept ontology enables only the selection and filtering of existing functions, as it does not describe the behaviour of such functions. The

Page 6

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

7

modeling support provided by semantic languages to describe such kind of function is still incomplete. The enactment post processing of the analysis results may require the use of aggregate functions (like count, sum, ...) that while are well defined and support in the relational world, are not still included in any semantic query or rule language. Current research efforts within the European integrated project SUPER are leading to the design of such language, thus enabling the formal definition of post processing function over analysis results [12]. We adopt this extension of the WSML logical expression to define our post processing functions. Finally, the evaluation templates, that specify how the results of the post processing step are visualized or reported to analysts, are defined as an ontology of presentation concepts. Such ontology defines the possible types of reporting templates and their configuration parameters. Then each peculiar template may be linked to its implementation (e.g. a proper XSLT stylesheet), that given a configured evaluation template, uses input data to generate the visual rendering for the analyst. The implementation of a evaluation template may be intended in a broader way and include actions like triggering alarms or sending emails.

3

Use Case Scenario: Semantic Reverse Business Engineering

The basic methods behind RBE were developed at the University of Wuerzburg, Germany [13], applied to the SAP R/3 system and converted into the tool Reverse Business Engineer by IBIS Prof Thome AG in collaboration with SAP AG. The fundamental idea of RBE is the scenario-based analysis of business processes and configuration of application systems (e.g. ERP or CRM) in an automated process [14]. RBE supports various analysis scenarios, like as-is analysis or user and role analysis. Each of them describes customer needs and focuses on different aspects within the information system. A scenario is constituted by a multiplicity of predefined business questions, which shall provide specific information with respect to transaction data, master data, organisational structures, and configuration settings [15]. In the process of an RBE analysis the customer chooses one or several analysis scenarios according to his/her needs. Based on the scenarios the relevant business questions are selected and composed to an RBE extractor. The results from the extractor are then imported into the RBE tool for evaluation purposes. Various analytical methods are used to evaluate the extracted data, e.g. to determine average cycle times or calculate KPIs. Finally the customer is provided with the outputs in form of reports. Reverse Business Engineering enables the analysis and improvement of existing business processes and system settings. As explained before, it gives great benefits by supporting various analysis scenarios according to user needs. However, RBE has some limitations regarding the degree of automation and the reuse of RBE contents. The key elements in the RBE analysis process are the business questions, which are used to collect details about the current implementation of

Page 7

SBPM 2008 Proceedings

8

Authors Suppressed Due to Excessive Length

a process and its usage. So far RBE is only applied to SAP systems, thus every business question contains proprietary patterns to query the SAP database. To use RBE for analysing other information systems the patterns of the business questions have to be adapted manually because of the peculiarity of each single system and the absence of a middle layer that hides these differences to the system. Hence modelling new business questions causes a lot of manual work and requires a substantiated knowledge about the data structure of the respective information system. Currently the selection of business questions is performed solely according to the chosen analysis scenario. Moreover, business questions are assigned to a standard process model for the purpose of evaluation, so if a company has individual processes that should be evaluated, it causes a lot of manual work to assign the business questions to the corresponding elements in those individual processes. The remainder of this section describes how our approach has been applied to RBE, yielding a prototype to perform semantic RBE (sRBE). 3.1

sRBE Analysis Process

The research activities of Semantic Reverse Business Engineering (sRBE) aim at introducing semantic technologies in the RBE process to augment its degree of automation and its flexibility. The goal is to provide a model to describe the sRBE content (i.e. business questions and business metrics) at an abstract level so that they can be defined and categorised regardless of the underlying technology in the adopted system. In line with the approach described in Section 2, the sRBE analysis process is also composed of the five phases (selection, configuration, execution, evaluation, and reporting). At the beginning of an sRBE analysis the customer defines his/her aims. Generally companies have concrete problems they want to resolve with sRBE, for example the sales manager is interested in all business exceptions that occurred in sales order processing in order to avoid those costly deviations from the standard sales processes. According to this goal the relevant business questions are selected. This selection is done automatically by choosing the corresponding concepts of the ontologies, e.g. analysis scenario and business area. The second phase in the analysis process is the configuration of the selected business questions. The business analyst can specify various parameters. For example by entering an analysis period the analysis results can be restricted in a way that only those instances are considered whose timestamp is between the start date and the end date. Subsequently the selected and configured business questions are executed to retrieve the analysis results. Generally a reasoner is used to query the repository that contains the instances. The evaluation phase deals with operating with the results of the executed semantic business questions. Operating means to compute business metrics, generate statistical information and benchmark the relevant processes. Finally the evaluated values have to be presented to the business analyst. This can be done by using spreadsheets and charts or by displaying the results in the context of the executed process model.

Page 8

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

3.2

9

Applying Semantics to Business Questions

Semantic business questions have to be derived from existing RBE business questions and described using ontological concepts. The semantic annotation of RBE content is performed by linking it to ontological concepts. On the one hand, this allows for mapping generic questions to domain specific ontologies and, hence, to consider specific issues and terminologies of the selected domain. On the other hand, the semantic business questions and metrics can be assigned to any customer-specific process model which is also described semantically and, thus, the individual processes of a company can be easily evaluated. The main concepts to classify the business questions are the following: – Question Type: Each business question belongs to one of the question types “List”, “Count”, or “Sum”, which determine the extraction and presentation of their answer. – Activity: Every business question refers to an executed activity. For example the business question “How many sales offers were approved?” refers to the activity “approve sales offer”. – Analysis Scenario: This concept classifies business questions according to the analysis scenarios they support, e.g. as-is analysis or exception analysis. – Analysis Period : By assigning this concept to business questions the result values can be constrained by a time slice. Note that the first three items allow the actual classification of analysis metrics while the last one can be considered an execution parameter. According to this distinction, we have modelled classification concepts inside the concept Business Question as reported in Listing 1.1 using the method explained in Section 2.2. 

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22



concept BusinessQuestion hasDataCategory impliesType DataCategory hasScenario impliesType AnalysisScenario belongsToBusinessFunction impliesType UPO#BusinessFunction concept DataCategory concept ConfigurationData subConceptOf DataCategory concept MasterData subConceptOf DataCategory concept OrganisationData subConceptOf DataCategory concept TransactionData subConceptOf DataCategory concept AnalysisScenario concept AnalysisOfExceptions subConceptOf AnalysisScenario concept AsIsAnalysis subConceptOf AnalysisScenario concept HarmonisationAndStandardisation subConceptOf AnalysisScenario

Listing 1.1. The BusinessQuestion concept

Page 9



SBPM 2008 Proceedings

10

Authors Suppressed Due to Excessive Length

In Listing 1.2 we can see an example business question, namely “Which sales orders were processed?”, have been modeled in the sRBE ontology. Since it is classified as a part of an as-is analysis scenario, belonging to an order processing business function and to a transaction data category, the corresponding concepts in the ontology have been linked to the business question, thus allowing selection. The relation “WhichSalesOrdersWereProcessed” instead models the execution parameters, such as the analysis period and the function of the successfully executed event. 

 1 2 3 4 5 6 7 8 9 10

11 12 13

concept WhichSalesOrdersWereProcessed C subConceptOf RBEO#BusinessQuestion nonFunctionalProperties dc#description hasValue ”Which sales orders were processed?” endNonFunctionalProperties hasScenario ofType RBEO#AsIsAnalysis hasQuestionType ofType RBEO#List hasDataCategory ofType RBEO#TransactionData belongsToBusinessFunction ofType BFO#OrderProcessing relation WhichSalesOrdersWereProcessed( ofType RBEO#SuccessfulExecutionEvent, ofType BFO#OrderProcessing, ofType ”http://ip−super.org/ontologies/BRO/20070801# MarketingAndSalesRole”, ofType RBEO#AnalysisPeriod) nonFunctionalProperties dc#description hasValue ”relation related to business question Which sales orders were processed?” endNonFunctionalProperties

  Listing 1.2. Example of a semantic business question: selection-oriented concept and result-oriented relation

As explained in Section 2.2, according to our modeling abstraction, the execution of each business question is performed by an axiom which is executed by a reasoner, as reported in Listing 1.3, while querying the results is accomplished by using the configured relation.



 1 2 3

4 5 6 7 8 9 10



axiom WhichSalesOrdersWereProcessed X definedBy ?pe[hasCreationTimeStamp hasValue ?date, occurredDuringProcessExecution hasValue ?proc, GeneratedBy hasValue ?actor] memberOf EVO# SuccessfulExecutionEvent and ?proc memberOf BFO#OrderProcessing and ?role[playedBy hasValue ?actor] memberOf BRO#MarketingAndSalesRole and ?period[hasStartValue hasValue ?start, hasEndValue hasValue ?end] memberOf RBEO# AnalysisPeriod and ?date > ?start and ?date < ?end implies WhichSalesOrdersWereProcessed(?pe,?proc,?role,?period).

Listing 1.3. Example of an execution axiom

Page 10



SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

11

The obtained results are the basis for further calculations, therefore metrics have to be defined and described semantically. A classification criteria is the concept Dimension with its specifications Time, Cost and Quality. An example of a metrics is “cancellation rate of sales orders”, which is calculated by dividing the results of the business questions “How many sales orders were cancelled?” by “How many sales orders were created?” [16]. 3.3

Implementation Experience

To test our approach, we have developed within the SUPER project an sRBE engine prototype and integrated it with the SUPER architecture. Figure 2 illustrates the overall architecture of the sRBE engine including its connection with the SUPER architecture. The sRBE engine itself is composed by three layers, the reasoning engine that provides support for querying and inferring over semantic data; the business logic that includes a set of predefined functions to support the analysis workflow as introduced in Section 2 and provides access to the reasoner; a Graphical User Interface (presented in Figure 3) that, using the functionalities provided by the business logic, allows the users to performs the sRBE process. The sRBE engine includes a Business Question Repository, where the modeled questions and a set of other ontologies that are used to define the Business Question taxonomy are stored. Analysis data are imported from the Semantic Service Bus provided by SUPER architecture, which includes the access to: the Business Process Library, that contains all the model of the deployed and logged processes; the Execution History, that contains all the log of the processes executions; and finally, any other repository (also non semantic) that contains data needed to analyse business processes (e.g. ERP data). Data exposed by the Semantic Service Bus are seamless integrated through the reasoner engine, that allows in this way to perform query over distributed data.

4

Related Work

The idea of using semantics to perform process analysis is not new. In 2002, Casati et al. [3] introduced the HPPM intelligent Process Data Warehouse (PDD), in which taxonomies are used to add semantics to process execution data and, therefore, support more business-like analysis for the provided reports. The work in [4] is a follow-up of the work in [3]. It presents a complete architecture for the analysis, prediction, monitoring, control and optimization of process executions in Business Process Management Systems (BPMSs). This set of tools suite is called Business Process Intelligence (BPI). Some differences of these two approaches to ours are that (i) taxonomies are used to capture the semantic aspects (in our case, ontologies are used), and (ii) these taxonomies are flat (i.e., no subsumption relations between concepts are supported). Hepp et al. [5] proposes

Page 11

SBPM 2008 Proceedings

Authors Suppressed Due to Excessive Length

sRBE Toolkit

sRBE Business Logic Reasoner Engine

Semantic Service Bus

sRBE GUI

Business Support Question Ontologies Repository

Semantic Wrapper

12

External Datasources (e.g., ERP data)

Business Process Library

Execution History

Fig. 2. Architecture of the sRBE prototype and its connection with the SUPER Semantic Service Bus.

merging Semantic Web, Semantic Web Services (SWS), and Business Process Management (BPM) techniques to build Semantic BPMSs. This visionary paper pinpoints the role of ontologies (and reasoners) while executing semantic analysis. However, the authors do not present any concrete implementations for their ideas. The works by Sell et al. [7] and O’Riain et al. [6] are related to ours because the authors (i) also use ontologies to provide for the semantic analysis of systems and (ii) have developed concrete tools to support such analysis. The main differences are the kind of supported analysis. The work in [7] can be seen as the extension of OLAP tools with semantics. The work in [6] shows how to use semantics to enhance the business analysis function of detecting the core business of companies. This analysis is based on the so-called Q10 forms. Alves de Medeiros et al. [17] contains an outlook on the use of semantics to improve the analysis provided by existing process mining and monitoring techniques. The core idea is to annotate event logs and models with ontologies in order to support analysis at the concept level. In fact, more from an event log point of view, Pedrinaci et al. [18] have defined the Event Ontology and the Process Mining Ontology. These two ontologies can be used to give semantics to the event types and the process instances in logs. For instance, it is possible to say that a process instance was successfully executed. Although the semantic extensions in [17,18] are necessary to realize our approach, the authors do not discuss how to use ontologies to facilitate an analysis based on scenarios. In other words, the focus is more on the actual answering of the questions rather than on also using semantics to classify and retrieve these questions. Our paper is the first one to

Page 12

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

13

Fig. 3. A screenshot of the sRBE GUI showing the Business Question selection facility.

explore the use of semantics for a scenario-based analysis and to show a concrete implementation in this direction, following the initial ideas presented in [19].

5

Conclusions

This paper presented an approach towards the adoption of semantics to support scenario-based analysis. The proposed semantic meta-model is suitable for any scenario-based analysis because it encompasses all of the phases necessary for the selection, configuration and execution of scenario-based metrics, as well as the evaluation and reporting of results. The immediate gain is the leverage of the scenario-based analysis techniques to the expressive power offered by semantic languages, which allows not only to describe data models but also functionalities and their execution logic. Additionally, the approach has been applied to the Reverse Business Engineering technique, one of the most important scenario-based analysis techniques in the context of business process analysis. This application emphasized the ben-

Page 13

SBPM 2008 Proceedings

14

Authors Suppressed Due to Excessive Length

efits that the introduction of semantics brings to RBE, such as a greater level of automation, generation of system-independent analysis, better reusability of sRBE content and better administration of sRBE content. Finally, as our approach is database independent, wider spread business questions can also be used as extractors to get and semantically annotate service based transaction data, e.g. for Business Intelligence (BI) purposes (like extractors for data warehouses). Future work will focus on refining our prototype and developing more domain ontologies for the support of semantic-based analysis scenarios, so that it can be tested on a real-life use case scenario.

References 1. M. Dumas, W.M.P. van der Aalst, and A.H.M. ter Hofstede. Process-Aware Information Systems: Bridging People and Software through Process Technology. 2005. 2. IBIS Prof. Thome AG. Reverse Business Engineering Plus. http://www.rbeonline.de. 3. F. Casati and M.-C. Shan. Semantic Analysis of Business Process Executions. In EDBT ’02: Proceedings of the 8th International Conference on Extending Database Technology, pages 287–296, London, UK, 2002. Springer-Verlag. 4. D. Grigori, F. Casati, M. Castellanos, U. Dayal, M. Sayal, and M.-C. Shan. Business Process Intelligence. Computers in Industry, 53(3):321–343, 2004. 5. M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel. Semantic Business Process Management: a Vision Towards Using Semantic Web services for Business Process Management. In IEEE International Conference on e-Business Engineering (ICEBE 2005), pages 535 – 540, 2005. 6. S. O’Riain and P. Spyns. Enhancing the Business Analysis Function with Semantics. In OTM Conferences (1), pages 818–835, 2006. 7. D. Sell, L. Cabral, E. Motta, J. Domingue, and R. Pacheco. Adding Semantics to Business Intelligence. In DEXA Workshops, pages 543–547, 2005. 8. European Project SUPER - Semantics Utilised for Process Management withing and between Enterprises. Technical report. 9. Michael K. Smith, Chris Welty, and Deborah L. McGuinness. Owl web ontology language guide. W3c recommendation 10 february 2004. 10. Ian Horrocks, Peter F. Patel-Schneider, Harold Boley, Said Tabet, Benjamin Grosof, and Mike Dean. Swrl: A semantic web rule language combining owl and ruleml. W3c member submission 21 may 2004. 11. Jos de Bruijn, Holger Lausen, Axel Polleres, and Dieter Fensel. The web service modeling language wsml: An overview. In York Sure and John Domingue, editors, ESWC, volume 4011 of Lecture Notes in Computer Science, pages 590–604. Springer, 2006. 12. Stijn Heymans, Cristina Feier, Jos de Bruijn, Stefan Zller, and Emilia Cimpian. Process ontology query language. Technical report, SUPER Integrated Project, 2007. 13. H. Wenzel. Reverse business engineering: Ableitung von betriebswirtschaftlichen modellen aus produktiven softwarebibliotheken. Published dissertation at the chair of business administration, University Wuerzburg, 1999. 14. A. Hufgard and W. Walz. The road behind, Continuous business improvement with Reverse Business Engineering. 2003.

Page 14

SBPM 2008 Proceedings

Using Semantics to Aid Scenario-Based Analysis

15

15. R. Thome and A. Hufgard. Avoiding bad choices. 2005. 16. C. Ebert. Best Practices In Software Measurement: How To Use Metrics To Improve Project And Process Performance. Springer, 2004. 17. A.K. Alves de Medeiros, C. Pedrinaci, W.M.P. van der Aalst, J. Domingue, M. Song, A. Rozinat, B. Norton, and L. Cabral. An Outlook on Semantic Business Process Mining and Monitoring. In OTM Workshops (2), pages 1244–1255, 2007. 18. C. Pedrinaci and J. Domingue. Towards an Ontology for Process Monitoring and Mining. In Proceedings of SBPM 2007 Semantic Business Process and Product Lifecycle Management in conjunction with the 3rd European Semantic Web Conference (ESWC 2007), Innsbruck, Austria, June 2007. 19. Irene Celino, Ana Karla Alves de Medeiros, Gernot Zeissler, Michael Oppitz, Federico Facca, and Stefan Z¨ oeller. Semantic business process analysis. In M. Hepp, K. Hinkelmann, D. Karagiannis, R. Klein, and N. Stojanovic, editors, Semantic Business Process and Product Lifecycle Management. Proceedings of the Workshop SBPM 2007., volume 251 of CEUR Workshop Proceedings. CEUR-WS.org, 2007.

Page 15

SBPM 2008 Proceedings

Towards Policy-Powered Semantic Enterprise Compliance Management - Discussion Paper Marwane El Kharbili1, Sebastian Stein1, Ivan Markovic2, Elke Pulvermüller3 1

IDS Scheer AG, ARIS Research Altenkesseler Str. 17, 66115 Saarbrücken, Germany {marwane.elkharbili, Sebastian.stein}@ids-scheer.com 2

SAP Research Center CEC Karlsruhe, SAP AG Vincenz-Prießnitz Str. 1, 76131 Karlsruhe, Germany [email protected] 3

Institute of Computer Science, University of Osnabrück Albrechtstr. 28, 49076 Osnabrück, Germany [email protected]

Abstract. An essential but difficult task to achieve in distributed enterprise systems is the management and enforcement of regulations and policies. We explore and discuss ideas for the implementation of enterprise wide compliance management. We propose an approach that builds on policies to realize compliance checking on semantic descriptions of enterprise models. This paper is meant to initiate a discussion about the pro and contra of our approach. Keywords: Ontologies, Enterprise Model, Business Processes, Compliance Management, Policies.

1 Introduction In past years, there was an intensive public discussion about financial scandals happening at major companies and corporations1. Compliance management is a broad term covering all activities and methods to ensure that a company follows all guidance and implements all measures required by an external or internal regulation. The process of ensuring regulatory compliance is highly-manual and error-prone, because it relies on audits realized by accredited auditing firms [2]. This process is also costly, incomplete, and leaves space for inaccuracy in compliance audits [2]. Ensuring a common understanding of regulations and being able to automate the process of regulatory compliance enforcement are the challenges ahead of compliance management. Current industrial approaches to compliance management rely on identifying a set of measures for ensuring compliance, such as the widely known Segregation of Duty (SoD). These measures are then hard-coded into the systems on

1

Such as Enron, WorldCom, Roche, Siemens, and Volkswagen.

Page 16

SBPM 2008 Proceedings

which these checks have to be run. This leads to compliance measures being harder to manage and to maintain. This is why formal modeling of compliance measures constitutes one promising approach to compliance management. In this paper, we explain the idea of semantic policy-based enterprise compliance checking. We first motivate the need for compliance management at the level of enterprise models and show the use of semantics for this considering current research. We follow up by using an example of an SoD policy for the use of policies for formal regulatory compliance management. Finally, we illustrate our ideas by making a proposal for a policy-based compliance ontology framework.

2 Enterprise Regulatory Compliance & Policies Regulations are usually described in a natural language document (as is the case for laws). These texts can be hardly understood by non-experts of the field covered by the regulation. In order to implement regulations, measures are defined, either in the form of policies or controls. Moreover, regulations can be structured and documented in compliance frameworks. The COSO2 (SOX [1] compliance) and COBIT3 (IT governance) frameworks are examples of this. In academia, there have been efforts to come up with compliance support [3, 4, 5, 6], mainly considering only business processes as the scope of compliance management problems. However, compliance covers many aspects of a business and ranges from financial laws to quality standards [2]. In [3] a similar observation is made. In [4] and [6], the authors rely on the definition of controls for implementing compliance. This approach requires predefinition of risks and rather fits to risk management approaches. A holistic framework for compliance management has to support a variety of compliance targets, which is why compliance management should be given the scope of the whole enterprise. Enterprise models seek to model all elements of an organization. Companies create enterprise models to represent their structure and dynamics. Guidelines to structure such a model exist like Zachman [7], TOGAF4 or ARIS [8]. Business processes are one of many elements of an enterprise model that is critical, carrying value-adding activities and accessing all elements of an enterprise model. Ontologies do not only bring the power of formal descriptions of models, they make automated inference on enterprise models possible. Their use allows “Achieving interoperability between multiple representations of reality […] between such representations and reality” [9]. Besides, comprehensive models of the enterprise exist already, such as results of the TOVE [19] project. However, such works do not rely on formal semantics which would enable service agents (e.g. as part of a semantic web services framework) to infer on and intelligently interact with instances of enterprise models. The latter would be an accelerator for the automation of BPM [20]. There are various research efforts made to formalize the underlying meta-

2

See: Committee of Sponsoring Organizations of the Treadway Commission: www.coso.org. See: Control Objectives for Information and related Technology framework: www.isaca.org. 4 See: The Open Group Architectural Framework (TOGAF), http://www.togaf.org/. 3

Page 17

SBPM 2008 Proceedings

models of enterprise models using ontologies [11, 12]. Such frameworks provide a unified view on business entities and their relationships (e.g. organizational and resource ontologies) that can be queried and built upon for semantic modeling of enterprise compliance. Enterprise models contain for example business process models and internal enterprise policies. Because of the high relevance of business processes for companies, research on business process management (BPM) has been active in finding ways of enriching business processes semantically [13, 14]. A set of languages and frameworks have been designed for this purpose, mostly coming from the semantic web services community ([10, 14]). Regulatory compliance restraints and guides states and interactions between entities involved in business processes. Using rules for this purpose is a proven technique for example in database research. In [21] the authors explain how to extend a compliance management framework with domain ontologies in OWL and modeling compliance using SWRL rules. However, this approach tackles compliance in the semantic web and does neither focus on enterprise models nor on distributed enforcement (necessary e.g. for open process choreographies). Modeling regulations by using policies provides a formal tool for declarative implementation of compliance management. Hence, maintaining compliance becomes an easier task since compliance measures are decoupled from the enterprise models and business processes they act on. While allowing consistent modeling, verification and enforcement of compliance measures, policy modeling allows for automated compliance management and auditing. It also makes splitting compliance management into policy management and policy implementation and enforcement possible. According to [16], semantic policies can reduce human error, simplify policy analysis, reduce policy conflicts, and facilitate interoperability. In the next section we give an example motivating our approach using policies.

3 Business Scenario belongsTo «instanceOf» OrganizationalEntity

Employee *

«Policy» Separation of Duty

* appliesOn

John : Employee

* *

«use» hasRole

hasRole «Role» «instanceOf»

Role

Accountant : Role

isPartOf «instanceOf» «Rule»

«Role»

SoD::Auditor/Accountant

Auditor : Role

«use» hasRole

Fig. 1. Organizational policy example: an employee entity cannot be both an accountant and an accounting auditor.

Our main concern is modeling regulatory policies. In order to explain our idea, we chose the example of Segregation of Duty (SoD, see Fig. 1). An SoD says that a certain individual (or Role) who is part of the organization cannot concurrently

Page 18

SBPM 2008 Proceedings

exercise a certain set of activities. Usually, each organization has its own SoD matrix. In the example, the regulation defines an SoD as a compliance measure. One of the rules implementing this particular SoD is shown next: If: (OA.Role.equals(“Auditor”)) && OA.Role.equals(“Accountant”)) Then: Violation = True

In this example, the auditor has to examine who was assigned bookkeeping and financial audit in order to ensure that both roles are not shared by one person or organization. With a policy modeling framework at hand, the problem of conducting compliance checks on an enterprise model is reduced to the problem of modeling adequate policies implementing the desired regulation. Policy frameworks provide means of verifying the modeled compliance measures and allow reusing previously modeled compliance measures.

4 A Policy Framework for Compliance Management Our approach is represented on a very high level in Fig.3. A semantic policy is designed to allow the modeling of regulations (e.g. BASEL II for the banking sector). Such policies are thus destined to be enforced on an enterprise ontology, which contains the resources, processes, and organizational entities upon which policies can be enacted. On this basis, we want to use the inference capacities delivered by reasoners to run compliance checking. We can identify a number of requirements on a policy framework for this purpose. Additionally to the functionality of modeling formal policies (i.e. a language and a modeling environment), policies must be checked for correctness (i.e. syntactical as well as functional tests available). The framework must also support policy enforcement and offer analysis functionalities. Since policies are destined to evolve with business processes and enterprise models they have been modeled for, change management aspects have to be considered. In Fig. 2 the structure of a policy framework for compliance management is sketched. The elements shown are needed at both design-time (compliance modeling) and at run-time (compliance checking and enforcement). In [2], an architecture is given where the ontology in Fig. 2 is used in order to implement a compliance management framework. A top layer is used for the modeling of high-level policies and the management of policies themselves. Such a layer allows expressing assertions on policy types, deontic statements, speech acts, meta-policies and management mechanisms such as delegation and domains of jurisdiction. Concrete implementation of policies (so called production rules) can be generated from the upper layers, and is dependent on the context of use. This is an advantage in comparison to direct modeling of compliance measures as SWRL rules in [21].

Page 19

SBPM 2008 Proceedings

Fig. 2. A policy framework for compliance management

Work on policies has delivered several policy frameworks that could serve our purposes, and we have retained the following three for evaluation: Ponder [18], KAoS [17] and Rei [16]. In [15], an extensive comparison of these frameworks is made. In our evaluation, the Rei framework presents many advantages, such as being defined semantically and providing a policy engine. We selected Rei for the Upper Level Policy Ontology (ULPO). Building upon the top layer, domain specific ontologies are designed to allow modeling regulations belonging to one particular domain. Each domain has specific types of constraints and standards or regulations that cover this domain. For example, ISO 27001 describes a standard for information systems security. Separating policies by domain is a necessary trade-off between complexity and scope of the policy. The ULPO provides means for integrating policies belonging to different domains. In the lowest part of Fig. 2, we have a layer for modeling rules. Rules are one intuitive way of implementing policies and contain the logic expressed by formal policies. Rules are also destined to be interpreted by target systems and executed. Providing the possibility to transform policies into rules expressed in targetlanguages would add more flexibility and reach to our approach.

4 Conclusions In this work we have introduced the concept of policy-based compliance checking. Outsourcing the complexity of regulations from business processes and enterprise models into policies allows for flexibility, reduces the complexity of these models, and enables automation of the activities related to compliance management. We have proposed an approach and sketched a policy framework for it. It is our aim to achieve automation of the compliance auditing process. We are currently investigating automated generation of rules from policies, which allows productive enforcement of compliance policies on a variety of platforms. Finally, we will pursue the integration of these elements in an industrial BPM framework, and show their usage in concrete regulatory compliance use cases. Acknowledgements. Our research on semantic compliance management and BPM is supported by the EU commission within the SUPER project: http://www.ip-super.org. References 1. Congress of the United States (2002). Public Company Accounting Reform and Investor Protection Act (Sarbanes-Oxley Act). Pub. L. No. 107-204, 116 Stat. 745.

Page 20

SBPM 2008 Proceedings

2. El Kharbili, M., Stein, S., Markovic, I. and Pulvermueller, E.: Towards a Framework for Semantic Business Process Compliance Management. In proceedings of the workshop on Governance, Risk, and Compliance on Information Systems (GRCIS). Montpellier, 2008. 3. Karagiannis, D.: A Business process Based Modeling Extension for Regulatory Compliance. In Multikonferenz Wirtschaftsinformatik 2008, Munich, 2008. 4. Namiri, K., Stojanovic., N.: A Formal Approach for Internal Controls Compliance in Business Processes. In 8th Workshop on Business Process Modeling, Development, and Support (BPMDS07), Trondheim, Norway, 2007. 5. Schmidt, R., Bartsch, C., Oberhauser, R.: Ontology-based representation of compliance requirements for service processes. In Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM 2007), 2007 6. Sadiq S., Governatori G., Namiri K.: Modeling Control Objectives for Business Process Compliance In Proceedings of the 5th International Conference, BPM 2007, Brisbane, Springer, 2007, pp.149-164. 7. Zachman, J. A.: A framework for information systems architecture. IBM systems journal, Volume 26, No. 3, pp 276-292, 1987. 8. Scheer, A.W.: ARIS - Business Process Frameworks. Third edition, Springer, Berlin (1999) 9. Hepp M.. Ontologies: State of the art, business potential, and grand challenges. Ontology Management: Semantic Web, Semantic Web Services, and Business Application, pp. 3–22. Springer. 2007. 10. http://www.ip-super.org/res/Deliverables/M12/D1.1.pdf. 11. Hepp M. et al.. Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In IEEE International Conference on e- Business Engineering (ICEBE 2005), pages 535–540, Beijing, China. 12. Mike Uschold, Martin King, Stuart Moralee, and Yannis Zorgios. The Enterprise Ontology. The Knowledge Engineering Review, 13, 1998. 13. Martin Hepp and Dimitru Roman. An Ontology Framework for Semantic Business Process Management. In 8th International Conference on Wirtschaftsinformatik 2007, pp. 423–440, Karlsruhe. 14. Markovic, I., Pereira, A.C., Stojanovic, N.: A Framework for Querying in Business Process Modelling. In Multikonferenz Wirtschaftsinformatik 2008, Munich, 2008. 15. Gianluca T. Bradshaw J.M., Jeffers R., Montanari R., Suri N. and Uszok A.. semantic web languages for policy representation and reasoning: A comparison of KAoS, Rei and Ponder. In The SemanticWeb - ISWC 2003. 16. Lalana Kagal. A Policy-Based Approach to Governing Autonomous Behavior in Distributed Environments. PhD Thesis. Faculty of the Graduate School of the University of Maryland . 2004. 17. Jeffrey M. Bradshaw, Stewart Dutfield, Pete Benoit, \& John D. Woolley. KAoS: Toward An Industrial-Strength Open Agent Architecture. Pp 375-418. 18. N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The ponder policy specification language. In Morris Sloman, editor, Proc. of Policy Worshop, 2001, Bristol UK, January 2001. 19. Fox, M.S. The TOVE Project: A Common-sense Model of the Enterprise. Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, Belli, F. et al. (Eds.), Lecture Notes in Artificial Intelligence # 604, Springer-Verlag, pp. 25-34. 1992. 20. M. Hepp, D. Roman. An Ontology Framework for Semantic Business Process Management, Proceedings of Wirtschaftsinformatik 2007. 21. F. Yip, N. Parameswaran and P. Ray. Rules and Ontology in Compliance Management. In proceedings of the 11th IEEE International Enterprise Distributed Object Computing Conference. IEEE Computer Society. 2007.

Page 21

SBPM 2008 Proceedings

Semantic Business Process Validation Ingo Weber1 , J¨org Hoffmann2 , and Jan Mendling3 1

3

SAP Research, Karlsruhe, Germany [email protected] 2 University of Innsbruck, STI, Austria [email protected] BPM Group, Queensland University of Technology, Australia [email protected]

Abstract. The use of formal semantics for the support of Business Process Management is an emerging branch of research, with substantial economic potential. In particular, business processes modelled in graphical notations such as BPMN can be semantically annotated to specify more precisely what the individual tasks in the process will be responsible for. This raises the need for, and opens up the opportunity to apply, semantic validation techniques: techniques that take the annotations and the underlying ontology into account in order to determine whether the tasks are consistent with respect to each other, and with respect to the underlying workflow structure. To this end, we introduce a formalism for semantic business processes, which combines definitions from the workflow community with definitions from AI; we introduce some validation tasks that are of interest in this context. We then make first technical contributions towards solving this kind of problem. We identify a class of processes where the validation tasks can be solved in polynomial time, by propagating certain pieces of information through the process graphs. We show that this class of processes is maximal in the sense that, with more general semantic annotations, the validation tasks become computationally hard. We outline how the validation information gathered can serve to automatically suggest bug fixes.

1

Introduction

One of the promises of service-oriented architectures is increased flexibility through loose coupling of components. In enterprise applications, Web services can be used to encapsulate business functionality. The process flow can then, to a large degree, be separated from the implementation of the process activities. This increased flexibility can be a key advantage when acting in rapidly changing markets. In such an environment, a business expert models a business process on a high level of abstraction, like the Business Process Modelling Notation (BPMN) [18]. Semantic techniques can then be used to help bridge between the high-level process and the actual IT infrastructure. Namely, the business expert can annotate the tasks in the process (the steps that are atomic from the business expert’s point of view) with semantic information relative to an ontology that formalises the underlying business domain. Then, based on a Semantic Web Services (SWS) infrastructure, advanced support – discovery, composition, mediation – for binding the process, i.e., for implementing it with concrete services, becomes possible.

Page 22

SBPM 2008 Proceedings

Since modelling is an error-prone activity, the above scenario calls for validation techniques: prior to trying to bind the process, validation should help to ensure that the process model as such makes sense. A validation method may be useful after binding the process, as well: being implemented at a more detailed level, the bound process may reveal flaws that were not visible at the BPMN level of abstraction. Possible validation questions are, for example: Is there an effect conflict, i.e., two tasks with conflicting semantic effects and no ordering constraint between them (simple example: two writeoperations in a database)? Is a particular task reachable, i.e., is there any execution of the process that involves the task? Is a particular task executable, i.e., is its semantic precondition guaranteed to be true when trying to execute it? Answers to these questions are certainly useful as a help for the modeller, and for binding the process; we will see that one can even design techniques that automatically suggest (potential) bug fixes. Traditional validation techniques, as considered in the workflow community (e.g. [24]) and the model checking community (e.g. [7]), do not deal with ontological axiomatizations, which are at the heart of the semantic annotations required in the above scenario. Hence mapping our validation problem into existing methodologies is, to say the least, problematic. Thus we suggest a different approach, Semantic Business Process Validation (SBPV), which is explicitly designed to deal with this kind of validation tasks. We introduce a formal execution semantics for semantic business processes in the context of axiomatizations, and we identify associated validation tasks. We make first technical contributions towards solving this kind of problem. Our SBPV formalism is a natural combination of definitions from the workflow community (e.g. [24,25]), and the AI actions and change community (e.g. [27,10,12]). The former deal with the semantics of workflow structures, via a notion of token passing adopted from Petri Nets. The latter deal with the semantics of logical preconditions and effects in the presence of a logical theory – the axioms of the ontology – constraining the behaviour of the underlying domain. In particular, this distinguishes us from all other works [15,6,22,20,21] extending Business Process validation beyond workflows (see Section 6 for details). We formalise the validation tasks outlined above. Thereafter: – We identify a class of processes, termed basic processes, where the validation tasks can be solved in polynomial time. Basic processes have no cycles, no branching conditions, and an ontology consisting of only binary clauses. Naturally, this deliberately restricted class covers only a subset of real-world processes. We specify validation algorithms inspired by the token passing that underlies the workflow semantics; instead of passing only tokens, logical information is propagated. Although the key ideas are straightforward, some of the details are quite intricate. – We show that the class of basic processes is maximal in the sense that, when allowing more general semantic annotations, then the validation tasks become computationally hard. In particular, this holds already for very simple branching conditions, and for Horn clauses instead of binary clauses. – We outline methods suggesting bug fixes, based on the information propagated by our validation algorithms. This suggests that, in general, one should try to obtain this information (rather than only “yes/pass” answers to the validation questions). Section 2 introduces our SBPV formalism. Sections 3 and 4 present our polynomialtime algorithms for basic processes, and our results their computational borderline.

Page 23

SBPM 2008 Proceedings

Section 5 outlines how bug fixes can be suggested, Section 6 discusses related work, Section 7 concludes. For space reasons, the presentation is very concise; many technical details (including all proofs), and more illustrative examples, are moved to [26].

2

Semantic Business Processes

We introduce a formalism, i.e., a formal execution semantics, for business processes whose tasks are annotated with logical preconditions and effects (Section 2.1). We then present a number of validation tasks that are of interest for such processes (Section 2.2). We illustrate the formalism with an example annotated BPMN process (Section 2.3). 2.1

Annotated Process Graphs

Our business processes consist of different kinds of nodes (task nodes, split nodes, . . . ) connected with edges. We will henceforth refer to this kind of graphs as process graphs. For the sake of readability, we first introduce non-annotated process graphs. This part of our definition is, without any modification, adopted from the workflow literature, following closely the terminology and notation used in [25]. Definition 1. A process graph is a directed graph G = (N , E), where N is the disjoint union of {n0 , n+ } (start node, stop node), NT (task nodes), NP S (parallel splits), NP J (parallel joins), NXS (xor splits), and NXJ (xor joins). For n ∈ N , IN (n)/OU T (n) denotes the set of incoming/outgoing edges of n. We require that: for each split node n, |IN (n)| = 1 and |OU T (n)| > 1; for each join node n, |IN (n)| > 1 and |OU T (n)| = 1; for each n ∈ NT , |IN (n)| = 1 and |OU T (n)| = 1; for n0 , |IN (n)| = 0 and |OU T (n)| = 1 and vice versa for n+ ; each node n ∈ N is on a path from the start to the stop node. If |IN (n)| = 1 we identify IN (n) with its single element, and similarly for OU T (n); we denote OU T (n0 ) = e0 and IN (n+ ) = e+ . The intuitive meaning of these structures should be clear: an execution of the process starts at n0 and ends at n+ ; a task node is an atomic action executed by the process; parallel splits open parallel parts of the process; xor splits open alternative parts of the process; joins re-unite parallel/alternative branches. The stated requirements are just basic sanity checks any violation of which is an obviously flawed process model. Formally, the semantics of process graphs is, similarly to Petri Nets, defined as a token game. A state of the process is represented by tokens on the graph edges. Like the notation, the following definition closely follows [25]. Definition 2. Let G = (N , E) be a process graph. A state t of G is a function t : E 7→ N; we call t a token mapping. The start state t0 is t0 (e) = 1 if e = e0 , t0 (e) = 0 otherwise. Let t and t0 be states. We say that there is a transition from t to t0 via n, written t →n t0 , iff one of the following holds: 1. n ∈ NT ∪ NP S ∪ NP J and t0 (e) = t(e) − 1 if e ∈ IN (n), t0 (e) = t(e) + 1 if e ∈ OU T (n), t0 (e) = t(e) otherwise. 2. n ∈ NXS and there exists e0 ∈ OU T (n) such that t0 (e) = t(e) − 1 if e = IN (n), t0 (e) = t(e) + 1 if e = e0 , t0 (e) = t(e) otherwise.

Page 24

SBPM 2008 Proceedings

3. n ∈ NXJ and there exists e0 ∈ IN (n) such that t0 (e) = t(e) − 1 if e = e0 , t0 (e) = t(e) + 1 if e = OU T (n), t0 (e) = t(e) otherwise. An execution path is a transition sequence starting in t0 . A state t is reachable if there exists an execution path ending in t. Definition 2 is straightforward: t(e), at any point in time, gives the number of tokens currently at e. Task nodes and parallel splits/joins just take the tokens from their IN edges, and move them to their OUT edges; xor splits select one of their OUT edges; xor joins select one of their IN edges. For the remainder of this paper, we will assume that the process graph is sound: from every reachable state t, a state t0 can be reached so that t0 (e+ ) > 0; for every reachable state t, t(e+ ) ≤ 1. This means that the process does not contain deadlocks, and that each completion of a run is a proper termination, with no tokens remaining inside the process. These properties can be ensured using standard workflow validation techniques, e.g. [24,25]. For the semantic annotations, we use standard notions from logics, involving logical predicates and constants (the latter correspond to the entities of interest at process execution time).1 We denote predicates with G, H, I and constants with c, d, e. Facts are predicates grounded with constants, Literals are possibly negated facts. If l is a literal, then ¬l denotes l’s opposite (¬p if l = p and p if l = ¬p); if L is a set of literals V then ¬L denotes {¬l | l ∈ L}. We identify sets L of literals with their conjunction l∈L l. Given a set P of predicates and a set C of constants, P[C] denotes the set of all literals based on P and C; if arbitrary constants are allowed, we write P[]. A theory T is a closed (no free variables) first-order formula. Given a set C of constants, T [C] denotes T with quantifiers interpreted over C. For the purpose of our formal semantics, T can be arbitrary. For computational purposes, we will consider the following standard restrictions. A clause is a universally quantified disjunction of atoms, e.g., ∀x.¬G(x) ∨ ¬H(x). A clause is Horn if it contains at most one positive literal. A clause is binary if it contains at most two literals. A theory is Horn (binary) if it is a conjunction of Horn (binary) clauses. Note that binary clauses can be used to specify many common ontology properties such as subsumption relations ∀x.G(x) ⇒ H(x) (φ ⇒ ψ abbreviates ¬φ ∨ ψ), attribute image type restrictions ∀x, y.G(x, y) ⇒ H(y), and role symmetry ∀x, y.G(x, y) ⇒ G(y, x). An example of a property that is Horn (but not binary) is role transitivity, ∀x, y, z.G(x, y) ∧ G(y, z) ⇒ G(x, z). An ontology O is a pair (P, T ) where P is a set of predicates (O’s formal terminology) and T is a theory over P (constraining the behaviour of the application domain encoded by O). Annotated process graphs are defined as follows. Definition 3. An annotated process graph is a tuple G = (N , E, O, A). (N , E) is a process graph, O = (P, T ) is an ontology, and A, the annotation, is a partial function mapping n ∈ NT ∪ {n0 , n+ } to (pre(n), eff(n)) where pre(n), eff(n) ⊆ P[], and mapping e ∈ OU T (n) for n ∈ NXS to (con(e), pos(e)), where con(e) ⊆ P[] and pos(e) ∈ {1, . . . , |OU T (n)|}. We require that: there does not exist an n so that T ∧ eff(n) is unsatisfiable or T ∧ pre(n) is unsatisfiable; there does not exist an e so that 1

Hence our constants correspond to BPEL “data variables” [17]; note that the term “variables” in our context is reserved for variables as used in logics, quantifying over constants.

Page 25

SBPM 2008 Proceedings

T ∧ con(e) is unsatisfiable; there do not exist n, e, and e0 so that e, e0 ∈ OU T (n), A(e) and A(e0 ) are defined, and pos(e) = pos(e0 ). We refer to cycles in (N , E) as loops; we refer to edges e for which A(e) is defined as case distinctions (sometimes, process graphs without loops and/or case distinctions will be of interest). We refer to pre(n) as n’s precondition, eff(n) as n’s effect (sometimes called postcondition in the literature), con(e) as e’s condition, and pos(e) as e’s position. The annotation of tasks – atomic actions that will on the IT level correspond to Web service executions – in terms of logical preconditions and effects closely follows Semantic Web service approaches such as OWL-S (e.g. [1,8]) and WSMO (e.g. [9]). All the involved sets of literals (pre(n), eff(n), con(e)) are interpreted as conjunctions.2 Similarly to Definition 1, the requirements stated in Definition 3 are just basic sanity checks. If a precondition/effect/condition contradicts the theory, then the respective task node/edge will never be applicable. The requirement on edge positions is a minor technical detail, stating that no two edges are assigned the same position. This closely corresponds to standard process languages such as BPEL [17], where the positions are assigned based on the order of appearance in the input file. This ensures that the outcome of an xor split is deterministic – if the xor split edges are annotated. Note here that Definition 3 allows A to be a partial function. That is, an arbitrary subset of the process may be not annotated. The rationale behind this is that validation will take place during modelling. In such a context, it is useful to allow validation of partially modelled – partially annotated – processes. The formal semantics is: Definition 4. Let G = (N , E, O, A) be an annotated process graph. Let C be the set of all constants appearing in any of the annotated pre(n), eff(n), con(n). A state s of G is a pair (ts , is ) where t is a token mapping and i is an interpretation i : P[C] 7→ {0, 1}. A start state s0 is (t0 , i0 ) where t0 is as in Definition 2, and i0 |= T [C], and i0 |= T [C] ∧ eff(n0 ) in case A(n0 ) is defined. Let s and s0 be states. We say that there is a transition from s to s0 via n, written s →n s0 , iff one of the following holds: 1. n ∈ NP S ∪ NP J ∪ NXJ , is = is0 , and ts →n ts0 according to Definition 2. 2. n ∈ NXS , is = is0 , and t0 (e) = t(e) − 1 if e ∈ IN (n), t0 (e) = t(e) + 1 if e = e0 , t0 (e) = t(e) otherwise, where either e0 ∈ OU T (n) and A(e0 ) is undefined, or e0 = argmin{pos(e) | e ∈ OU T (n), A(e) is defined,is |= con(e)}. 3. n ∈ NT ∪ {n+ }, ts →n ts0 according to Definition 2, and either: A(n) is undefined and is = is0 ; or is |= pre(n) and is0 ∈ min(is , T [C] ∧ eff(n)) where min(is , T [C] ∧ eff(n)) is defined to be the set of all i that satisfy T [C] ∧ eff(n) and that are minimal with respect to the partial order defined by i1 ≤ i2 :iff {p ∈ P[C] | i1 (p) = is (p)} ⊇ {p ∈ P[C] | i2 (p) = is (p)}. An execution path is a transition sequence starting in a start state s0 . A state s is reachable if there exists an execution path ending in s. Given an annotated process graph (N , E, O, A), we will use the term execution path of (N , E) to refer to an execution over tokens that acts as if A was completely undefined (in which case Definition 4 essentially simplifies to Definition 2). 2

It is easy to extend our formalism to allow arbitrary formulas for pre(n), eff(n), con(e); extending the actual validation leads to harder decision problems, and remains future work.

Page 26

SBPM 2008 Proceedings

The part of Definition 4 dealing with n ∈ NP S ∪ NP J ∪ NXJ parallels Definition 2, and should be easy to understand: the tokens pass as usual, and the interpretation remains unchanged. For n ∈ NXS , the definition says that an output edge e0 is selected where either e0 is not annotated, or e0 has the smallest position among those edges whose condition is satisfied by the current interpretation, is . Note that this is a hybrid between a deterministic and a non-deterministic semantics, depending on how many output edges are annotated. If all edges are annotated, then we have a case distinction as handled in, e.g., BPEL, where the first case (smallest position) with satisfied condition is executed (Section 11.2 in [17]). If no edges are annotated, then the validation must foresee that an arbitrary case distinction may be created later on during the modelling, so no assumptions can be made on the form of that case distinction, so any possibility must be taken into account. Definition 2 just generalises these two extremes in the straightforward way. Let us finally consider the “semantic” part of Definition 4, dealing with task nodes and their semantic annotations. First, note that we interpret the quantifiers in T over the constants C that are used in the annotation. The rationale is that the process should execute based on those entities that are actually available (it remains open to examine whether it makes sense to drop this assumption). Consider now the start states, of which there may be many, namely all those that comply with T , as well as eff(n0 ) if that is annotated. This models the fact that, at design time, we don’t know the precise situation in which the process will be executed. All we know is that, certainly, this situation will comply with the domain behaviour given in the ontology, and with the properties guaranteed as per the annotation of the start node (if any). The semantics of task node executions is a little more intricate. If A(n) is undefined, then the logical state i remains of course unchanged. If A(n) is defined, then pre(n) is required to hold. The tricky bit lies in the definition of the possible outcome states i0 in the latter case. Our semantics defines this to be the set of all i0 that comply with T and eff(n), and that differ minimally from i. This is where we draw on the AI actions and change literature, for a solution to the frame and ramification problems. The latter problem refers to the need to make additional inferences from eff(n), as implied by T ; this is reflected in the requirement that i0 complies with both. The frame problem refers to the need to not change the previous state arbitrarily – e.g. if a web service makes a booking via account A, then the balance of account B should remain unaffected; this is reflected in the requirement that i0 differs minimally from i. More precisely, i0 is allowed to change i only where necessary, in the sense that there is no i00 that makes do with fewer changes. This semantics follows the possible models approach (PMA) [27]; while this approach is not uncontroversial, it underlies most of the recent work on formal semantics for execution of Semantic Web services (e.g. [14,5,11]). Alternative semantics from the AI literature (see [12] for an excellent overview) could be used in principle; this is a topic for future research. 2.2

Validation Tasks

We now formally define the validation properties that we consider in this paper. We start with a definition of parallel – un-ordered – task nodes; some of the validation tasks will be about potential conflicts between such nodes.

Page 27

SBPM 2008 Proceedings

Definition 5. Let G = (N , E, O, A) be an annotated process graph, n1 , n2 ∈ N . We say that n1 and n2 are parallel, written n1 k n2 , if there exist execution paths t1 and t2 of (N , E) so that n1 is executed before n2 on t1 , and n2 is executed before n1 on t2 . We will show in Section 3 how parallel nodes can be detected. Note that t1 and t2 here are token executions, ignoring the semantic annotations; i.e., Definition 5 refers only to the workflow structure. We are interested in validating the following properties: Definition 6. Let G = (N , E, O, A) be an annotated process graph. Let n ∈ NT ∪ {n+ }. Then, n is reachable iff there exists a reachable state s so that ts (IN (n)) > 0; n is executable iff, for all reachable states s with ts (IN (n)) > 0, we have s |= pre(n). G is reachable (executable) iff all n ∈ NT ∪ {n+ } are reachable (executable). Let n1 , n2 ∈ NT , n1 k n2 . Then, n1 has a precondition conflict with n2 if T ∧ eff(n1 ) ∧ pre(n2 ) is not satisfiable; n1 and n2 have an effect conflict if T ∧ eff(n1 ) ∧ eff(n2 ) is not satisfiable. Consider first the notions of reachable and executable task nodes n. Reachability is important because, if n is not reachable, then it is completely useless; this certainly indicates a malfunction of the process model. As for executability, if n is not executable then the process may reach a state where n is active – it has a token on its incoming edge – but its prerequisites for execution are not given. If the process is being executed by a standard (non-semantic) engine, e.g. based on BPEL, then the implementation of n will be executed anyway, which may lead to errors. In general, the possibility to activate a task without establishing its precondition indicates that the process model does not take sufficient care of achieving the relevant conditions in all possible cases. Reachability and executability are both temporal properties on the behaviour of the process, and of course it may be of interest to allow arbitrary validation properties via a suitable temporal logic (see e.g. [19,23]). We leave this open for future work; the focus on reachability and executability is, in that sense, an investigation of special cases. Note that these special cases are of practical interest (perhaps more so than the fully general case allowing arbitrarily complex quantification which may never be used in practice). Consider now the precondition and effect conflicts from Definition 6. Such conflicts indicate that the semantic annotations of different task nodes may be in conflict; n1 may jeopardise the precondition of n2 , or n1 and n2 may jeopardise each other’s effects.3 If n1 and n2 are ordered with respect to each other, then this kind of conflict cannot result in ambiguities and should not be taken to be a flaw; hence Definition 6 postulates n1 k n2 . Apart from that, it is debatable to some extent whether such conflicts represent flaws, or whether they are a natural phenomenon of the modelled process. Our standpoint is that they are flaws, because in a parallel execution it may happen that the conflicting nodes appear at the same time. Obviously, once parallelity is clarified, precondition and effect conflicts can be found by a simple loop over all pairs of parallel task nodes. In the remainder of the paper, we will assume that such a loop has completed successfully, i.e., without finding any conflicts. Note that reachability can be established as a side-effect of executability: 3

For illustration it is useful to consider the special case where T is empty: then, a precondition conflict means there exists l ∈ eff(n1 ) ∩ ¬pre(n2 ); similarly for effect conflicts.

Page 28

SBPM 2008 Proceedings

Lemma 1. Let G = (N , E, O, A) be an annotated process graph without case distinctions where (N , E) is sound and all n ∈ NT are executable. Then all n ∈ NT are reachable. We consider process graphs without case distinctions in our validation technique described in Section 3 below. We provide methods only for checking executability. With Lemma 1, once that is established, we know that reachability is also given. Note that Lemma 1 does not hold if G has case distinctions: a node may not be reachable because an edge condition on e may never become true. 2.3

An Example Process

We consider a sales order process that is inspired by the BPEL specification [3]. Figure 1 shows this process in BPMN, where as usual the symbol + represents parallel splits and joins. The receipt of a sales order triggers three concurrent activities: initiating the production scheduling, deciding on the shipper, and drafting a prize calculation. Once the shipper has been decided, the price calculation can be completed and the logistics can be arranged. After the latter, also the production scheduling can be completed. Finally, the invoice is processed. The process model is obviously sound in the workflow sense. However, let us take the perspective of a German machine producer (we call it GMP) that manufactures to order. This involves that production, delivery, and pricing are tailored to the product requirements of the customer. Production Scheduling

Production

Decide on Shipper

Arrange Logistics

Draft Price Calculation

Complete Price Calculation

Invoice Processing

Receive Order

Fig. 1. Example of a sales order process modeled in BPMN. GMP has used the depicted process successfully and without encountering any problems for years to produce and deliver to the national market. Now the company has made the decision to consider also international orders and delivery. Recently, it has received an order of 10 impulse turbines for power generation from a country that currently faces political unrest. According to German legislation such a delivery requires approval from the Bundesamt f¨ur Wirtschaft und Ausfuhrkontrolle (BAFA), i.e. the authority that controls German foreign trade. In order to deal with the complexity of international trade, GMP has decided to replace some of its production steps with services from experts. The key account manager for international clients has signed agreements with respective service providers. The new set of services including their

Page 29

SBPM 2008 Proceedings

preconditions and postconditions are summarized in the top part of Table 1. In particular, the Production Scheduling, the Production, and Arrange Logistics tasks are now provided by new services that have more specialized preconditions and postconditions. Further, a domain theory, depicted in the bottom part of Table 1, has beed added, capturing some simple domain constraints that can be easily validated by stakeholders if a systems analyst translates them into natural language. Finally, Table 1 introduces thee process variables that capture the state of the involved business objects: order (o), production (p), calculation (c), shipper (s), and shipment (sh). Activity Receive Order Production Scheduling

Precondition

Postcondition orderReceived(o) productionScheduled(o,p)

orderReceived(o) orderApproved(o) Production productionScheduled(o,p) productionCompleted(o,p) calculationPrepared(o,c) calculationUpdated(o,c) Decide on Shipper orderReceived(o) shipperDecided(o,s) Arrange Logistics shipperDecided(o,s) calculationUpdated(o,c) calculationPrepared(o,c) shipmentApproved(o,sh) Draft Price Calculation orderReceived(o) calculationDrafted(o,c) Complete Price Calculation calculationPrepared(o,c) calculationFinalized(o,c) Invoice Processing productionCompleted(o,p) calculationFinalized(o,c) orderCompleted(o) Purpose Definition Order status ∀x : ¬orderReceived(x) ∨¬orderCompleted(x) Production status ∀x, y : ¬productionScheduled(x,y) ∨¬productionCompleted(x,y) Calculation status ∀x, y : calculationDrafted(x,y) =⇒ calculationPrepared(x,y) ∀x, y : calculationUpdated(x,y) =⇒ calculationPrepared(x,y) ∀x, y : ¬calculationDrafted(x,y) ∨¬calculationFinalized(x,y) ∀x, y : ¬calculationUpdated(x,y) ∨¬calculationFinalized(x,y) ∀x, y : ¬calculationPrepared(x,y) ∨¬calculationFinalized(x,y) ∀x, y : ¬calculationDrafted(x,y) ∨¬calculationUpdated(x,y) Order approval ∀x, y : shipmentApproved(x,y) =⇒ orderApproved(x)

Table 1. Semantic annotations in the example. Top: preconditions and postconditions of the services. Bottom: axioms of the domain theory. In a discussion with the production engineer the key account manager is embarrassed to learn that his set of services will not work for the production process of GMP, although the workflow of this process is sound. There are: Non-executable tasks: In order to cover the BAFA export approval, GMP has chosen a shipper whose Arrange Logistics service provides a postcondition of shipmentApproved if BAFA approves the delivery. Furthermore, GMP selected a Production Scheduling service that requires orderApproved as a precondition in order to block production until it is clear that the ordered goods can be exported. This alone is fine since, by the axiomatization, an order is approved if its shipment is approved. However, there is now a dependency between arranging logistics and scheduling the production, which determines the order of these two activities. Logistics must

Page 30

SBPM 2008 Proceedings

be arranged before the production is scheduled. This is not done by the process, and hence the precondition of production scheduling is not fulfilled when trying to execute it. Precondition conflicts: The new Arrange Logistics task require the calculation c to be prepared (drafted or updated), so that it can be updated. However, Complete Price Calculation is not ordered with respect to Arrange Logistics, and if it is executed first then the status of c changes to finalized. Effect conflicts: The new Arrange Logistics and Production services of GMP update the prize calculation, as indicated by their effect calculationUpdated. On the other hand, the parallel task Complete Price Calculation establishes the conflicting postcondition calculationFinalized. Hence, whether or not the calculation is finalized at the end of the process depends on which one of these nodes is executed last – a clearly undesirable behavior.

3

Polynomial-Time Validation Methods

We now specify an efficient validation algorithm for a particular class of processes, namely: Definition 7. Let G = (N , E, O, A), O = (P, T ), be an annotated process graph. G is basic if it contains neither loops nor case distinctions, and T is binary. Note that our example from Section 2.3 is a basic annotated process graph. For complexity considerations, we will in the following assume fixed arity, i.e., a fixed upper bound on the arity of the predicates P. This is a realistic assumption because predicate arities are typically very small in practice (e.g., in Description Logics the maximum arity is 2). Given a process graph whose annotations mention the constants C, and a set L of literals (such as a task node effect), in the following we denote L := {l ∈ P[C] | T ∧ L |= l}, i.e., L is the closure of L under implications in the theory T . Since T is binary, L can be computed in polynomial time given fixed arity [4]. Note that, with binary T , an effect conflict can be easily detected as the (negative) overlap of the closure over the effect sets, i.e., T ∧ eff(n1 ) ∧ eff(n2 ) is not satisfiable iff eff(n1 ) ∩ ¬eff(n2 ) 6= ∅, and similarly for precondition conflicts. Our validation algorithm performs three steps: (1) Determine a numbering # of the edges E so that, whenever task node n1 is ordered before task node n2 in every process execution, then #(IN (n1 )) < #(IN (n2 )). (2) Using #, execute an M -propagation algorithm that determines all pairs of parallel task nodes. (3) Determine, for each edge e, the set of literals that are always true when e is active. In what follows, we explain in detail only step (3). Steps (1) and (2) can be looked up in [26]. The outcome of step (2) is a matrix M ∗ whose rows and columns correspond to the set of edges E. M ∗ ji is a Boolean referring to the edges e, e0 with #(e) = i, #(e0 ) = j; this value determines parallelity in the following sense: Lemma 2. Let G = (N , E, O, A) be an annotated process graph. There exists exactly one M -propagation result M ∗ , and for all n1 , n2 ∈ NT we have n1 k n2 iff #(IN (n )) M ∗ #(IN (n21 )) = 1. The time required to compute M ∗ is polynomial in the size of G.

Page 31

SBPM 2008 Proceedings

M ∗ is used to determine all parallel task nodes, and, with that, whether any precondition or effect conflicts arise. If so, those are indicated to the human modeller. Once the conflicts have been resolved, step (3) of our validation algorithm can be started. This step determines, for each edge e, the set of literals that is always true when e is active. The computation is based on propagation steps, updating sets of literals that are assigned to the edges. Upon completion, these literal sets are exactly the desired ones. Definition 8. Let G = (N , E, O, A) be a basic annotated process graph without effect conflicts, and with constants C. We define the function I0 : E 7→ 2P[C] ∪ {⊥} as I0 (e) = eff(n0 ) if e = OU T (n0 ), I0 (e) = ⊥ otherwise. Let I, I 0 : E 7→ 2P[C] ∪ {⊥}, n ∈ N . We say that I 0 is the propagation of I at n iff one of the following holds: 1. n ∈ NP S ∪NXS , and I(IN (n)) 6= ⊥, and for all e ∈ OU T (n) we have I(e) = ⊥, and I 0 is given by I 0 (e) = I(IN (n)) if e ∈ OU T (n), I 0 (e) = I(e) otherwise. 2. n ∈ NP J , and for all S e ∈ IN (n) we have I(e) 6= ⊥, and I(OU T (n)) = ⊥, and I 0 is given by I 0 (e) = e0 ∈IN (n) I(e0 ) if e = OU T (n), I 0 (e) = I(e) otherwise. 3. n ∈ NXJ , and for all T e ∈ IN (n) we have I(e) 6= ⊥, and I(OU T (n)) = ⊥, and I 0 is given by I 0 (e) = e0 ∈IN (n) I(e0 ) if e = OU T (n), I 0 (e) = I(e) otherwise. 4. n ∈ NT , and I(IN (n)) 6= ⊥, and I(OU T (n)) = ⊥, and    eff(n) ∪ (I(IN (n)) \ ¬eff(n)) e = OU T (n) #(e) 0 I (e) = I(e) \ ¬eff(n) M ∗ #(IN (n)) = 1 and I(e) 6= ⊥   I(e) otherwise If A(n) is not defined then eff(n) := ∅ in the above. If I ∗ results from starting in I0 , and stepping on to propagations until no more propagations exist, then we call I ∗ an I-propagation result. Definition 8 is a little hard to read but relies on straightforward key ideas. The definition of I0 is obvious. For split nodes (case 1), the OUT edges simply copy their sets from the IN edge. For parallel joins (case 2), the OUT edge assumes the union of I(e) for all IN edges e; for xor joins (case 3), the intersection is taken instead. The handling of task nodes (case 4) is somewhat more subtle. First, although there are no effect conflicts it may happen that a parallel node has inherited (though not established itself, due to the postulated absence of effect conflicts) a literal which the task node effect contradicts; hence line 2 of case 4.4 Second, we must determine how the effect of n may affect any of the possible interpretations prior to executing n. This is non-trivial due to the complex semantics of task executions, based on the PMA [27] definition of minimal change for solving the frame problem, c.f. Section 2.1. Our key observation is: (*) With binary T , if executing a task makes literal l false in at least one possible interpretation, then ¬l is necessarily true in all possible interpretations. 4

The interactions of parallel nodes with conflicting effects may be quite subtle, and require a much more complicated propagation algorithm. We are currently working on such an extended algorithm, which will allow the user to tolerate effect conflcits if desired.

Page 32

SBPM 2008 Proceedings

Due to this observation, it suffices to subtract ¬eff(n) in the top and middle lines of the definition of I 0 (e): l does not become false in any interpretation, unless ¬l follows logically from eff(n). Importantly, (*) does not hold for more general T ; see [26] for an example where T is Horn. Note that the I-propagation algorithm ignores preconditions. This may seem odd since preconditions T play an essential part in executability. The trick is as follows. Let, for any edge e, e be the set of literals that will always be trueTwhen e is active. Then, assuming that all task nodes are executable, one can prove that e = I ∗ (e). Now, if all T ∗ nodes are executable, then, since (e) = I (e), we have pre(n) ⊆ I ∗ (IN (n)) for all n ∈ NT ∪ {n+ }. Conversely, if n ∈ NT is the first node where pre(n) 6⊆ I ∗ (IN (n)), then all of n’s predecessorsTare executable and we know, with the same arguments as before, that I ∗ (IN (n)) = IN (n). Hence n is not executable. We get: Theorem 1. Let G = (N , E, O, A) be a basic annotated process graph without effect conflicts. There exists exactly one I-propagation result I ∗ . G is executable iff, for all n ∈ NT ∪ {n+ }, pre(n) ⊆ I ∗ (IN (n)). With fixed arity, the time required to compute I ∗ is polynomial in the size of G.

4

Computational Borderline

Since the class of basic processes can be validated in polynomial time, it is interesting to determine the computational borderline of this positive result: What happens if we generalise this class? We give negative results for allowing case distinctions, and for allowing more general ontologies. It is an open question whether or not loops, or structured loops, can be dealt with efficiently. We are currently investigating this. Lemma 3. Assume an annotated process graph G = (N , E, O, A) that is basic except that A(e) may be defined for some e ∈ E. Deciding whether G is reachable is NP-hard. Deciding whether G is executable is coNP-hard. Lemma 4. Assume an annotated process graph G = (N , E, O, A) that is basic except that T is not binary. Deciding whether G is reachable is Σ2p -hard in general, and NPhard if T is Horn. Deciding whether G is executable is Π2p -hard in general, and coNPhard if T is Horn. Importantly, Lemma 4 holds even for propositional T . Our main result regarding the computational borderline follows directly from Lemmas 3 and 4: Theorem 2. Assume an annotated process graph G = (N , E, O, A). Unless P = NP, neither reachability nor executability can be decided in polynomial time if one of the following holds: G is basic except that it may contain case distinctions; G is basic except that T may involve Horn clauses. Basic process graphs are generous in that they allow predicates with large arity, and in that they do not require the start node effect eff(n0 ) to be complete. One might wonder if sacrificing this generality could buy us anything. This is not the case: the proofs of Lemmas 3 and 4 do not exploit this feature. Corollary 1. Theorem 2 holds even if predicate arity is fixed to 0, and eff(n0 ) is complete, i.e., if for every p ∈ P[C]: either p ∈ eff(n0 ) or ¬p ∈ eff(n0 ).

Page 33

SBPM 2008 Proceedings

5

Fixing Bugs

It would of course be desirable to be able to not only inform the human modeller that a process is flawed, but to also suggest actual fixes for the detected bugs. This is a highly difficult task – in general, it requires an understanding of the intentions behind the process; such an understanding may not be apparent from the semantic annotations. This notwithstanding, it is interesting to observe that some bug fixes are possible based on the information determined by our algorithms from Section 3. Assume that task node n is not executable. Assume further that we know the set of literals I(n) that are true in any state where n is activated – i.e., in case the process is basic, I(n) is the set I ∗ (IN (n)) as per Definition 8. Then we can fix this bug by inserting a new task node n0 before n, and setting pre(n0 ) := I(n) and eff(n0 ) := pre(n). SWS discovery and composition can then be used to seek an implementation of n0 . In other words, we can try to automatically fill the holes in the process implementation. Note that this is only possible if our validation method answers not only “yes/no”; as is the case for our method from Section 3, the method needs to know internally which literals will be true at which points. If the validation method uses a decision procedure, like e.g. a SAT solver, for a case where answering “yes/no” is hard, then one may have to make extra arrangements to also obtain the information I(n). If n1 and n2 have a precondition or effect conflict, then it may be possible to resolve that conflict via enforcing an ordering constraint between n1 and n2 . In many cases, this can be done by inserting an additional parallel split and join between n1 and n2 . Note that, for effect conflicts, there is a choice between the two possible orders. Note also that such a bug fix, and also the bug fix for executability outlined above, may introduce new bugs. Some of these issues can be overcome, e.g., by careful selection of SWS for the implementation, and/or by careful selection of ordering constraints.

6

Related Work

Verification of business process models has been a field of intense research since several years; see, e.g. [24] as an entry point into this literature. Indeed, as stated, for its workflow part our formalism adopts the Petri Net based approach from [24], in the notation used by [25].5 What distinguishes our approach from all this work are our use of preconditions and effects, and of ontologies – of logical theories T – that constrain the behaviour of the underlying business domain. In particular, while propositional preconditions and effects can be modelled in terms of Petri Nets, this is not possible for our theories T and their impact on the semantics of executing tasks (as per Definition 4). Some other works have appeared that extend Business Process validation beyond workflows; none of these works explores the same direction as ours, but it is worthwhile to point out the differences. The most closely related work is [13], which annotates task nodes with logical effects, and uses a propagation algorithm somewhat reminiscent of our I-propagation. There are, however, a number of important differences between the two approaches. [13] allow CNF effects, which are considerably more expressive 5

We choose [25] since it works on the workflow model itself, rather than on a corresponding Petri Net, and hence simplifies our notations.

Page 34

SBPM 2008 Proceedings

than our purely conjunctive effects; on the other hand, their propagation algorithm is exponential in the size of the process (the size of the propagated constructs multiplies at every xor join), in stark difference to our polynomial time methods. Further, [13] consider neither preconditions nor logical theories that constrain the domain behavior. Finally, while we provide a formal execution semantics and prove our methods correct relative to that semantics, the work of [13] proceeds at a rather informal intuitive level. Another related work is [15], which like our work introduces a notion of “semantic” correctness. Namely, [15] allow to annotate pairs of tasks as “exclusive” (respectively “dependent”), meaning they cannot (they must) co-occur in any process. This is a limited form of semantic annotation – not incorporating any logical formalism – which can be modelled in our approach using appropriate preconditions and effects, with empty theory T . In that sense, [15] handles an interesting special case of our framework. In terms of its terminology, [6] is strikingly similar to our approach, extending process models with predicates, constants, and variables. However, the meaning of these constructs is very different from ours, using them to specify constraints on role assignments, i.e., on the assignment of resources to tasks – while in our model, logics is used to detail the actual execution of the process within a given business domain. [16] describe methods to check compliance of a process with a set of “rules”. This is related to our approach in that a theory T could (to some extent) be defined to model such rules; but not vice versa since we build on general logics, while [16] covers some practical special cases. Perhaps more importantly, the focus of [16] is different from ours, concentrating on role assignments as well as “actions” to be triggered during process execution. [22] also deal with rules and business processes, but in a setting where the rules model (parts of) the workflow itself, rather than the surrounding ontology. Another somewhat related line of work is data-flow analysis, where dependencies are examined between the points where data is generated, and where it is consumed; some ideas related to this are implemented in the ADEPT system [20,21]. Data flow analysis builds on compiler theory [2] (where data flows are examined for sequential programs mostly); it does neither consider ontologies (theories T ) nor logical conflicts, and hence explores a direction complementary to ours.

7

Conclusion

In Semantic Business Process Management, validation techniques are needed that consider the semantic annotations to check whether a process is consistent. Such validation techniques are semantic in that they need to work with ontologies. We have devised a first formalism for this kind of validation. We have identified efficient algorithms for a class of processes, and proved that this class is maximal with respect to the expressiveness of the annotation. Our next step will be to explore our notions from a more practical perspective. In particular, we believe certain classes of loops can be addressed with variants of our current algorithms.

References 1. A. Ankolekar et al. DAML-S: Web service description for the semantic web. In ISWC, 2002.

Page 35

SBPM 2008 Proceedings

2. A. Aho, R. Sethi, and J. Ullman. Compilers: principles, techniques, and tools. AddisonWesley, 1986. 3. T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business Process Execution Language for Web Services, Version 1.1. Specification, BEA Systems, IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, 2003. 4. B. Aspvall, M. Plass, and R. Tarjan. A linear-time algorithm for testing the truth of certain quantified boolean formulas. Information Processing Letters, 8:121–123, 1979. 5. F. Baader, C. Lutz, M. Milicic, U. Sattler, and F. Wolter. Integrating description logics and action formalisms: First results. In AAAI, 2005. 6. E. Bertino, E. Ferrari, and V. Atluri. The specification and enforcement of authorization constraints in workflow management systems. ACM Transactions on Information Systems Security, 2(1):65–104, 1999. 7. E. Clarke, O. Grumberg, and D. Peled. Model Checking. The MIT Press, 2000. 8. The OWL Services Coalition. OWL-S: Semantic Markup for Web Services, 2003. 9. D. Fensel et al. Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag, 2006. 10. T. Eiter and G. Gottlob. On the complexity of propositional knowledge base revision, updates, and counterfactuals. Artificial Intelligence, 57(2-3):227–270, 1992. 11. G. De Giacomo, M. Lenzerini, A. Poggi, and R. Rosati. On the update of description logic ontologies at the instance level. In AAAI, 2006. 12. A. Herzig and O. Rifi. Propositional belief base update and minimal change. Artificial Intelligence, 115(1):107–138, 1999. 13. George Koliadis and Aditya Ghose. Verifying semantic business process models in interoperation. In Intl. Conf. Services Computing (SCC 2007), 2007. 14. C. Lutz and U. Sattler. A proposal for describing services with DLs. In DL, 2002. 15. L. Thao Ly, S. Rinderle, and P. Dadam. Semantic correctness in adaptive process management systems. In BPM, 2006. 16. Kioumars Namiri and Nenad Stojanovic. A model-driven approach for internal controls compliance in business processes. In SBPM, 2007. 17. OASIS. Web Services Business Process Execution Language Version 2.0, April 2007. 18. OMG. Business Process Modeling Notation – BPMN 1.0. http://www.bpmn.org/, 2006. 19. A. Pnueli. The Temporal Logic of Programs. In IEEE Annual Symposium on the Foundations of Computer Science, 1977. 20. M. Reichert, S. Rinderle, and P. Dadam. ADEPT workflow management system: Flexible support for enterprise-wide business processes. In BPM, 2003. 21. M. Reichert, S. Rinderle, U. Kreher, and P. Dadam. Adaptive process management with ADEPT2. In ICDE, 2005. 22. S. Sadiq, M. Orlowska, and W. Sadiq. Specification and validation of process constraints for flexible workflows. Journal of Information Systems, 30(5):349–378, 2005. 23. W. van der Aalst, H. de Beer, and B. van Dongen. Process mining and verification of properties: An approach based on temporal logic. In OTM Conferences, 2005. 24. W. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002. 25. J. Vanhatalo, H. V¨olzer, and F. Leymann. Faster and more focused control-flow analysis for business process models though sese decomposition. In ICSOC, 2007. 26. I. Weber, J. Hoffmann, and J. Mendling. Semantic business process validation. Technical report, University of Innsbruck, 2008. Available at http://members.deri.at/˜joergh/papers/trsbpm08.pdf. 27. M. Winslett. Reasoning about actions using a possible models approach. In AAAI, 1988.

Page 36

SBPM 2008 Proceedings

GoMoKIT: Towards an applicable goal-oriented Business Process Modelling approach for Knowledge-Intensive Tasks -

Daniela Feldkamp, Simon Nikles University of Applied Sciences Northwestern Switzerland, School of Business, Riggenbachstr. 16, 4600 Olten, Switzerland {daniela.feldkamp, simon.nikles}@fhnw.ch

Abstract. The Business Process Execution Language (BPEL) connects the benefit of service-oriented architecture and business process modelling by using standard control constructs to define the interactions between Web Services. The usage of predefined control constructs is efficient for production oriented business processes, but it leads to inflexible process models, which do not reach the challenges of today’s enterprises. To cope with increasing changes, uncertainty and unpredictability they have to be flexible and adaptable. We present an approach which combines well defined process models with goaldriven parts to reach less complex process models and more flexibility and adaptivity during runtime. Keywords: BPEL, Knowledge-intensive task, SOA

1

Introduction

Adaptivity and flexibility are the most important challenges of today’s business [1]. Enterprises which meet these challenges are able to cope with increasing changes, uncertainty and unpredictability. Since the early 90s the IT wants to support businesses to reach more flexibility and adaptivity by separating the process logic from business application up to the implementation of workflow management systems, which separates the process flow from the different tasks. But, it was realized quite soon, that workflow management systems are mainly useful for wellstructured processes. They lack flexibility in process execution. An alternative approach towards agility takes into account that every business application is based on rules to conduct the business logic. When compliance requirements increased, along with the demand for business flexibility the business rules approach emerged. Service-oriented Architecture inherently enables flexibility and adaptivity through choreography of services where each service can select and invoke any other web service. The Business Process Execution Language for Web Services (BPEL) supports the specification for coordination and composition of services [2]. Workflows are composed in BPEL using standard control constructs, like switch or

Page 37

SBPM 2008 Proceedings

sequence. The use of predefined control constructs can lead to complex process models, which are hard to maintain if all possible variants of knowledge intensive tasks and especially all rare and exceptional cases are respected. When the tasks are mutually depending on each other, this modelling sometimes is even impossible. Like mentioned by Hepp and Roman modelling the process flow has several disadvantages hence a declarative process description is preferred instead [13]. But the use of standard control constructs has the advantage of efficiency in automated workflows. To achieve more flexibility we provide an approach, which combines the benefit of BPEL and a goal-driven approach used for unstructured process parts. These unstructured process parts are modelled more abstractly at design time whilst providing the necessary conditions to ascertain the flow of these parts during runtime regarding the case. Modelling business processes more abstractly has the benefits of having a good starting point for discussions or supports discovering similar business processes [12]. The abstract parts are modelled using business rules and semantic technologies.

2

Related Works

A number of approaches to compose services exist, which emerged from the workflow and AI planning research community [3]. The workflow-based composition methods are mainly manual. Abstract process models are captured, whose tasks are related to real web services, which can be selected dynamically. There exist several techniques for web service composition based on AI planning, like rule-based planning and the situation calculus. Our approach is to combine approaches of both communities. For the static part, we use a model, which is bound to real web services, additionally we use the approach of OWL-S which provides a web service language, directly related to AI planning[4]. Their preconditions and postconditions specify the state change during execution of services. Theses preconditions and postconditions are widely used in planning.[5] In [6] an approach is presented, whose goals are decomposed in several sub goals, which are related to plans of processes. Unfortunately the explicit modelling of goals and their relation to sub goals in a hierarchical way leads to inflexibility. In [7] an approach is represented, where goals are also decomposed in sub goals. A planner helps to organize the sequence of sub goals and assigns services to realize them under given policies or constraints. In our approach, we combine these goal-driven approaches with the workflow based composition and OWL-S to create static process models and dynamic process models as well. The problem is, that business users are familiar with modelling of processes using common notations as BPMN, but expressing goals and processes using OWL-S is much more difficult and unusual. Our modelling approach proposes the application of SBVR, which is provided by the OMG[8]. The vocabulary of rules is represented as ontology, which can base on existing ontologies, like ontologies for the modelling of commercial and public enterprises provided by the TOVE 1 project. 1TOVE-Project:

http://www.eil.utoronto.ca/enterprise-modelling/tove/

Page 38

SBPM 2008 Proceedings

The advantage of using ontologies for representing facts and terms lies in higher expressiveness and organization wide common vocabulary.

3

Example

Figure 1 illustrates a simplified example for approving a building application. The process model describes the flow from storing the application data to a simple check whether there are building restrictions conflicting with the application ending with a complex verification including inspection on location, revision by an expert panel, checking of natural, environmental and historical agencies etc. Store Application Form

Formal check of Application Form

no

Notify user

Is formal correct

Change project yes Check environmental compatibility

Outside inspection

Historical preservation investigation

Outside inspection

Ask Mayor

Is building project is less than 50 m to natural water

Ask Mayor

Is building older than 100 years?

Check layout plan

Outside inspection

Ask Mayor

Does the building fit to the environment

Check layout plan

Outside inspection

Ask Mayor

Near industrial area?

Fig. 1 Example building process

4

GoMoKIT – Approach

For the structured part we use BPEL. As BPEL only provides standard control constructs, which can lead to complex process models, we use a goal driven approach to achieve flexibility during runtime. To avoid the necessity of extending the BPEL standard, we want to implement a web service which provides the additional functionalities for process orchestration and execution during runtime. Regarding our example shown in figure 2, we replace the complex part of the process using an additional object type, the so-called “variable process” [9]. This object type is related to a pool of tasks. The execution of these tasks is determined at runtime and hence, we avoid modelling them strictly. Additionally the object type is related to a rule set, which combines several rules, which are used to inference knowledge regarding the case. For instance, a building, which is older than 100 years, is a historical building. Because it is easier for business people to express their business rules using “structured English” we use the Semantics of Business Vocabulary and Rules (SBVR).

Page 39

SBPM 2008 Proceedings

The task pool contains several sub tasks. The sub tasks are executed to fulfil a specific goal. Therefore, we explicitly express the goals utilise the SBVR formalism. This goal is decomposed into sub goals which can be fulfilled by the tasks of the task pool. We relate therefore each task of the task pool to a sub goal. We add preconditions which specify what conditions have to be fulfilled before the task can be invoked and postconditions which define what the execution of the task effects. All conditions are expressed also using SBVR. Figure 2 shows the introduced process modelled with the GoMoKIT approach. The complex part of Figure 1 is replaced with the activity “Check Application” which is expected to achieve the goal ”Application is approved“. It is related to a rule-set containing two rules. The first rule expresses, that all buildings must be farther than 50 m from natural water and the second rule expresses, that a historical building is older than 100 years. This rule-set has to be executed first to inference knowledge regarding the current case. After the execution of the rules the tasks of the task pool can be invoked. In this example seven tasks are combined in the task pool. For each task the sub goal, its preconditions and postconditions are defined, such as the task “Historical Preservation Investigation“. After execution of the task the goal “Historical preservation investigation is approved” is fulfilled. The postcondition “Historical preservation investigation is accepted or not” specifies, that after the execution of the task the historical preservation investigation is accepted or denied. The precondition “building is a historical building“ defines, that the task should be invoked only when a building is older than 100 years.

Fig. 2 Task pool belonging to the “Building application” process and defining Subtasks with their goals, preconditions and postconditions.

5

Formalization

For the static part of the process model we use BPEL. The task pool is described using OWL-S. Every task of the task pool is described as an atomic process.

Page 40

SBPM 2008 Proceedings

Preconditions, postconditions and goals are expressed using the precondition, effect and result-concepts of OWL-S. Therefore, the rules, preconditions, goals and postconditions expressed in SBVR have to be transformed to a formal modelling language which can be executed by a rule engine.

Fig. 3: Example building process with variable process containing a main goal and rules pointing to a task pool 5.2 Runtime approach To demonstrate our approach we assume that we have a building which is older than 100 years, more than 50 m away from natural water and fits to the surroundings. The first activities (“Storing the application data”, “Formal Check” and the statement) of the process are executed by the BPEL engine. The variable process part relates to a web service, which provides the functionalities for executing rules, planning and executing the sub tasks. This web service gets the rule-set and the OWL-S-file as input. First, the rules are executed. In this use case two rules must be executed and both rules will be fired, regarding our case. The knowledge is stored in a database which is used for the whole process and therefore can be accessed by the variable process. After the execution of the rules, the service ontology is parsed to get the main goal, which is specified as effect of the OWL-S profile. All atomic processes are parsed to get these tasks which fulfil the main goal. If no main goal is found, an exception must be thrown to the BPEL-engine. In our use case the main goal is to approve the application, what is fulfilled by two tasks (“Send application is Accepted Notification” and “Send application is not accepted notification”). The preconditions of the found tasks are used to get the previous tasks, by parsing the postconditions and goals of the other tasks of the task pool. If tasks are found which have no preconditions or whose preconditions can be fulfilled without executing a previous task, these tasks will be executed first. In our case, this applies to

Page 41

SBPM 2008 Proceedings

“Check Layout Plan“, because it has no precondition and to “Historical Preservation Investigation”, because the precondition can be met by means of the knowledge stored in the database. These two tasks are the starting points of the sub process, from which the process is planned.

Check Layout Plan

Historical Preservation Investigation

Send application is not accepted notification

Fig. 3: Plan regarding the case Because we have modelled the sub process using OWL-S, we have to export them to executable models. The transformation from OWL-S to BPEL is presented in [10].

6

Conclusion

In this paper we have shown how structured and unstructured parts can be combined to one process, to avoid a complex process models by abstracting the complex part using an additional object type. We have represented an approach of combining the static and dynamic parts by using BPEL, semantic technologies and business rules. We have tried to keep the modelling simple, so business users can model the processes without an IT expert. Moreover, we have shown how this approach can be executed. This approach leads to more flexible and adaptable processes. Further works have to be done to transform the rules, preconditions, postconditions and goals from SBVR to an executable rule language. Additionally, we have to find a strategy for the execution part. If two tasks are executed parallel, we have to make sure, that the two tasks may not overwrite their result. Concerning the modelling user interface, facilities as input checking and support (e.g. selection of attributes) have to be complemented.

7

1. 2.

References

Hammer, M. and J. Champy, Reengineering the Corporation. 1993, New York. Harper Collins Publishers. Alonso, G., et al., Web Services, Concepts, Architectures and Applications. 2004: Springer Verlag.

Page 42

SBPM 2008 Proceedings

3. 4. 5. 6.

7. 8. 9.

10. 11. 12. 13.

Rao, J. and X. Su. A Survey of Automated Web Service Composition Methods. in First International Workshop, SWSWPC 2004. 2004. Springer Berlin / Heidelberg. Grosof, B.i.N., et al. Description Logic Programs: Combining Logic Programs with Description Logics. in WWW 2003. 2003. ACM. Sutton, S.M.J., Preconditions, Postconditions, and Provisional Execution in Software Processes. 1995. Greenwood, D. and G. Rimassa. Autonomic Goal-Oriented Business Process Management. in ICAS '07: Proceedings of the Third International Conference on Autonomic and Autonomous Systems. 2007. IEEE Computer Society. Kaiser, M. and J. Lemcke. Towards a Framework for Policy-Oriented Enterprise Management. in AAAI Spring Symposium,AI Meets Business Rules and Process Management. 2008. AAAI Press. OMG, Semantics of Business Vocabulary and Business Rules Specification. 2006. Feldkamp, D., K. Hinkelmann, and B. Thönssen. KISS- Knowledge-Intensive Service Support: An Approach for Agile Process Management. in Advances In Rule Interchange and Applications, International Symposium RuleML 2007. 2007. Springer-Verlag. Feldkamp, D. and N. Singh. Making BPEL Flexible. in AAAI Spring Symposium,AI Meets Business Rules and Process Management. 2008. AAAI Press. Liu, R. and A. Kumar. An analysis and taxonomy of unstructured workflows. in BPM 2005 : business process management 2005. Springer, Berlin. Dietz, J.L.G., The deep structure of business processes, Communications of the ACM, Volume 49 , Issue 5 (May 2006), pp. 58 - 64 http://portal.acm.org/citation.cfm?id=1125976. Hepp, M. and Roman, D.: An Ontology Framework for Semantic Business Process Management, proceedings of the 8th international conference Wirtschaftsinformatik 2007, February 28 - March 2, 2007, Karlsruhe. In: Oberweis, A; Weinhardt, C.; Gimpel, H.; Koschmider, A.; Pankratius, V.; Schmizler, B.: eOrganisation: Service-, Prozess, Market-Engineering, Vol. 1, Universitaetsverlag Karlsruhe, pp. 423-440.

Page 43

SBPM 2008 Proceedings

Organization Structure Description for the Needs of Semantic Business Process Management Witold Abramowicz1 , Agata Filipowska1 Monika Kaczmarek1 , Carlos Pedrinaci2 , Monika Starzecka1 , and Adam Walczak1 1

2

Pozna´ n University of Economics, Department of Information Systems, 60-967 Pozna´ n, Poland, {W.Abramowicz, A.Filipowska, M.Kaczmarek, M.Starzecka, A.Walczak}@kie.ae.poznan.pl WWW home page: http://kie.ae.poznan.pl Knowledge Media Institute, The Open University, Milton Keynes, UK, [email protected] WWW home page: http://kmi.open.ac.uk

Abstract. Various attempts have been undertaken to further automate the BPM lifecycle. One of the recent initiatives in this area is the Semantic Business Process Management approach as pursued within the SUPER project. It aims at bridging the gap between business and IT worlds by increasing the degree of automation within the BPM lifecycle using Semantic Web and Semantic Web services technologies. In order to fulfil the SBPM vision, enterprises as well as their environment need to be properly described. The main contribution of this paper is a set of ontologies for describing organizational structures and examples showing how they may be combined with further organizational information, e.g., business functions and business roles, to support the automatic analysis of business processes.

1

Introduction

A business process may be defined as a set of related, ordered activities that contribute to the production of good(s) or the delivery of some service. It emphasises how the work is done within an organization and by its organization members. Therefore, organizations have their own context for any running business process even if they operate in the same domain. This context embraces information like used resources, strategies, enterprise structure as well as roles and functions. However, when modelling business processes using current standardized notations (e.g. BPMN) a lot of information, especially on organizational aspects, cannot be represented. Various attempts were undertaken to achieve automation of the BPM lifecycle. One of the most advanced initiatives in this area is the concept of Semantic Business Process Management developed within the SUPER project (Semantic Utilised for Process Management with and between Enterprises). It aims at

Page 44

SBPM 2008 Proceedings

bridging the gap between business and IT worlds by increasing the degree of automation within the BPM lifecycle using Semantic Web and Semantic Web services technologies. In order to fulfil the SBPM vision, apart from the semantic description of the process flow (control structure), the process content description is also required. The process content relates to the enterprise and its environment and therefore, must rely on a proper organization description. Furthermore, for these aspects to take part in any automated processing they need to be expressed in a formal and machine readable form. The goal of this paper is to present a set of ontologies that support capturing organisational information as required for realizing the Semantic Business Process Management vision. We present four ontologies supporting the semantic representation of a process content and position them within the entire organizational framework developed within the SUPER project. The overall approach we propose in based on the use of ontological descriptions of process flow enriched with additional descriptions of the related resources, the organisational entities involved, the roles required, etc as proposed earlier in [1]. The remainder of the paper is organized as follows: first, we discuss the scope for the semantic description of an organization. Then, four ontologies, namely Organizational Structure Ontology, Organisational Units Ontology, Business Functions Ontology and Business Roles Ontology are shortly described followed by an example of process description with the use of developed ontologies. Finally, we position our work within the state of the art in the area of semantic representation of an enterprise. Finally we present some conclusion and introduce lines for future research.

2

Semantic Representation of Organization

In order to describe an organization for the needs of the Semantic Business Process Management, an appropriate vocabulary needs to be provided. It should allow for the description of both processes and process artefacts (process content). As mentioned, the volume of knowledge needed to adequately describe all organizational details relevant to any given element of a business process is immense. In order to represent this knowledge, relevant contextual information need to be extracted as well as important elements and aspects need to be identified. The main aspects that need to be captured are the process structure and enterprise domain specific terms (see Figure 2). The process related vocabulary is important to ensure a proper and unambiguous representation of control flow of processes within and between enterprises, while the latter part of stack is to provide a specific representation of a domain of given organization. Therefore, the process-related information (i.e. process ontologies) describes the structure of a process (i.e. tasks, control structures, links etc.), whereas organisation related ontologies provide a description of enterprise artefacts (i.e. actors, functions etc.) that are utilised or involved in the process realization. The domain ontologies provide the additional information specific to an organization from a given do-

Page 45

SBPM 2008 Proceedings

al on ati s nis gie ga lo Or nto O

D On oma to in log ies

main. As already stated in the introduction, the focus of this paper is on the organizational ontologies that provide a high-level view on the organization and process-related space. Therefore, it is to provide vocabulary and constraints for describing the environment in which processes are carried out from the organization’s perspective i.e. to allow describing actors, roles and other resources that may be referred to in the process definitions [1].

Process Ontologies Task 2 Task 1 Task 3

Fig. 1. SBPM Ontology Stack

Within the SUPER project we identified the following areas of the organisation description: business functions, business roles, organisational units, organisational structure, process resources, enterprise strategy and modelling guidelines. Each area is addressed by the respective ontology. All ontologies form an ontology stack for the needs of organizational aspects representation and usage within the business process modelling phase. The approach applied in SUPER was built based on previous achievements in the field of organisation modelling and was shaped by an extensive BPM practice while the preceding approaches involved mainly traditional managerial concepts. Hence, the SUPER view is more compact (e.g. it decomposes the institutional internal structure into functions and roles) whereas it also seems to be less human-centred (comparing e.g. skills and staff elements to resources of a process). The important similarities embrace the more general view on the organization; highlighting the elements that influence the institutional environment (i.e. strategy and modelling guidelines) in a comprehensive manner. Defining a fully comprehensive model of an enterprise, is a particularly challenging and demanding task which would require an extremely extensive and complex conceptualisation which it would be difficult to manage, adapt, and

Page 46

SBPM 2008 Proceedings

extend. Therefore, we propose instead a modular ontology stack that provides basic notions, systematizes them and thus provide the foundation for further development able to address the needs of a particular enterprise. Below a short description of ontologies constituting the SUPER organisational ontologies stack follows: – Business Functions - providing vocabulary to describe the hierarchy of different functions that may be carried out within a company (e.g. marketing, finance, HR) in order to enable vendor and domain independent classification of company processes and process fragments providing abstraction over single tasks constituting processes. – Business Roles - representing roles in the organisation e.g. Designer, Process Modeller, IT Expert, CEO. – Organizational Structure and Organisational Units Ontologies presenting detailed view on the organisational structure of an entity being described. – Process Resources - describing applications and resources that should be spent when carrying out processes (e.g. documents, IT systems, or any other resources needed to accomplish a task) or that may be a result of a certain task in a process. – Enterprise Strategy - in order to model information related to an enterprise strategy, targeted markets, beneficiaries of the company and some surroundings that influence the processes carried out in a company. – Modelling Guidelines - used to describe policies and rules that should be taken into account during processes modelling. In the following sections, the Business Organizational Structure Ontologies as well as the Functions and Business Roles Ontologies constituting a part of the ontologies stack are presented. The final shape (concepts and relations) of ontologies is a result of thorough analysis of the most representative ERP systems together with the critical approach towards the related work described in section 7. The expert knowledge was also an important source of inspiration. All mentioned ontologies were modelled using the WSML formalism.

3

Organization structure ontology

The Organizational Structure Ontology (OSO) focuses on supporting the definition of organisational structures. Following literature from this domain, the organisational structure may be defined as a structure and/or hierarchy of an organization and how its constituents work together to achieve common goals. Therefore, an organizational structure encompasses: departments, employees, their responsibilities, resources etc. as well as relations among them. The Organizational Structure Ontology is designed as an upper level ontology and therefore provides a main structure and relations aiming at achieving the domain independency. OSO structure is a result of analysis and mixture of a few described in a literature organisational structure models. The developed structure was based and/or inspired by [2–7].

Page 47

SBPM 2008 Proceedings

Figure 3 depicts the proposed structure of OSO. For readability purposes, all designed relations, not just subsumption ones, are included in the figure.

is-a

Organisation

consists of

Legal Entity consists of

ms

or perf

Business Function

Non-legal Entity

plays

Role

is-a

is-a

a is-

has Sub-Unit

Organisational Position

ks or

es

ir qu re

as

Organisational Unit assigned to

w

Resource

owns owns / has access

Skills has

Person

owns / has access

Fig. 2. Organizational Structure Ontology

The structure of the developed ontology makes it easy for other ontologies created within SUPER to import OSO concepts and use them as super concepts (e.g. Business Roles Ontology, Business Functions Ontology, Resource Ontology, and finally Organizational Unit Ontology may import OSO). OSO links all organizational ontologies developed so far in the SUPER project and enables description of organizational structure. The following concepts are included in the OSO ontology: – Organization - a social arrangement which pursues collective goals, which controls its own performance, and which has a boundary separating it from its environment Legal Entity - an entity that can enter into a legal contract [2]. – Non-legal Entity - an entity within a company with a role and business function assigned. It is a coherent formation in a company structure, but has no entitlement to act as an autonomous participant of economical processes [2]. – Organizational Unit - “any recognized association of people in the context of an enterprise. In a hierarchical structure, it may be a corporation, a division,

Page 48

SBPM 2008 Proceedings

– –

– –

– –

4

a department, a group or a team. In addition, it may be a committee, a task force, a project management organization, a class (for education) and so on” [4]. Business Function - functional area of an enterprise such as Human Resources, Sales Management, etc. Role - a common super type for elements that define roles. It provides a common root for roles in organizations as well as roles in processes. A role defines a set of expected behaviours, prerogatives and obligations featured by an actor [4]. Person - a human being regarded as an individual; an employee. Skills - a capability having two following features: it refers to a potential actor that is a person; the ability must be practiced or demonstrated to some measurable degree (eg. driving license, fluent German command, etc.)[2] Organisational position - defines the role of one or more people in an organization unit (eg. sales assistant, secretary) [4]. Resource - an entity that can be used or consumed while carrying out some activity or business process [2].

Organization units ontology

This ontology is designed to provide a common vocabulary for description of ”any recognized association of people in the context of the enterprise. In a hierarchical structure, it may be the corporation, a division, a department, a group or a team. In addition, it may be a committee, a task force, a project management organization, a class (for education) and so on”[4]. However, a variety of existing departments as well as naming standards, forced us to make some simplification. The developed ontology includes only the most common organizational departments. We assumed that we are modelling Organizational Units Ontology for a production enterprise (therefore, in order to describe some highly specific organizational units of e.g. publishing house or security company, appropriate concepts should be defined). The Figure 4 depicts the idea of OUO, whereby the arrows in the figure represent the is-a relation. As we decided to use Organizational Unit definition proposed by OMG in [4], we divided all units into temporary and permanent ones. Temporary units are entities, that are created in order to carry out a task, project etc. They exist in an organizational structure as long as the task or project is carried out, and disappear upon its completion. Permanent Units depicted in the figure above, were chosen as a result of analysis of different organizational structures of existing companies and organizations available in the Internet and SAP Solution Maps. Chosen units form a group that is common for many organizations being also domain-independent.

5

Business Functions and Business Roles Ontology

Within this section we give a short overview of Business Functions and Business Roles Ontology.

Page 49

SBPM 2008 Proceedings

Organisational Unit

Project Unit Temporary Organisational Unit

Marketing Dept.

Team / Task Unit

Permanent Organisational Unit

FinanceDept.

Committee Unit

HR Dept.

International Affairs Dept.

Management Dept.

Sales Dept.

R&D Dept.

Public Relations Dep. Production / Operational Dept.

Procurement Dept.

Logistics Dept.

Administration Dept. Facilities / Inventory Dept.

Customer Service Dept.

Fig. 3. Organizational Units Ontology

For a more comprehensive description please refer to [8]. The purpose of the Business Functions Ontology (BFO) is to provide foundation for structuring and defining business functions. As a business function, we understand the functional area of an enterprise such as Human Resources Management, Sales Management, etc. [8]. The BFO concept hierarchy consists of two parallel structures: one for function structure description and the other to group concepts representing activities connected or being part of a given functional area. The function sub-tree reflects main functional areas of the company e.g. Sales and Management. The ontology allows organizing knowledge on functions performed in the enterprise and explains what type of tasks are parts of those functions. BFO allows also decomposing business functions into smaller units (sub-functions). In the functional approach, the structure of the business organization is being (partially) expressed with the functions carried out by an abstract entity (a group, an agent or a department). BFO has been created in order to provide a skeleton of business functions that would be common for every enterprise, regardless of the domain the enterprise operates in. The BFO ontology is a complete construction, nonetheless it is supposed to be a comprehensive - yet generic - starting point for further development. Therefore, BFO includes only the high level view on the functional side of an enterprise that should be extended by domain-specific ontologies.

Page 50

SBPM 2008 Proceedings

In turn, the BRO ontology introduces the vocabulary needed to describe roles of both internal and external actors as performers of process’ tasks. Therefore, the purpose of the Business Roles Ontology (BRO) is to specify the common meaning of concepts related to roles acquired and played by actors within the organizational microenvironment. We define a BusinessRole as a set of expected behaviours, prerogatives and obligations featured by an actor. Any actor may play more than one role and these roles may change depending on the situation (context). Three main elements of the BRO knowledge model encompass: InternalRole, ExternalRole and InternalRoleType concepts. Although BRO is a generic, top-level ontology, it aims at the fulfilment of the mentioned constraints and provides a minimal, yet comprehensive, set of concepts. By a microenvironment we mean both the inside structure of an organization or an enterprise and its close surroundings. The ontology is designed in a way that supports its further development and extensions.

6

Example

This section presents a simple business process described using organizational ontologies. We decided to keep the example very simple to assure clarity intelligibility of presented idea. The process was modelled using Business Process Modelling Notation (BPMN) serialised to sBPMN (ontological version of the BPMN specification developed within the SUPER project [9]. The example presents an internal process of ordering printing paper in the Human Resources Department. It includes the following steps: 1. An employee goes to an office assistant and informs her about the shortage of printing paper. 2. The office assistant contacts a warehouse manager and places the appropriate order. 3. The warehouse manager makes the reservation for the paper in the system. 4. The delivery man delivers the paper to the office. To describe the process, respective elements of the company must be described. This includes the description of the actors involved (i.e. office assistant, warehouse manager and delivery man), the functions performed by them as well as organisational units implicated. Let’s name the office assistant MrsA. She works on position of an office manager. As an office manager, her roles in the company are: managing human resources and managing office. The following listing presents definition of appropriate instances of ontology concepts in WSML.

Page 51

SBPM 2008 Proceedings

instance ManagingOfficeRole memberOf bro#OrganizationalAndAdministeringRole instance HumanResourcesManagingRole memberOf bro#HRMRole instance OfficeManager memberOf oso#OrganizotionalPosition playsRole hasValue {HumanResourcesManagingRole, ManagingOfficeRole} assignedTo hasValue {ouo#HRDepartment} instance MrsA memberOf oso#Person worksAs hasValue {OfficeManager}

MrB works as a warehouse manager in the Inventory Department, thus his only role in the company is managing the warehouse. instance ManagingWarehouseRole memberOf bro#ResourceAdministeringRole instance WarehouseManager memberOf oso#OrganizationalPosition playsRole hasValue {ManagingWarehouseRole} assignedTo hasValue {ouo#InventoryDepartment} instance MrB memberOf oso#Person worksAs hasValue {WarehauseManager}

MrC works as a delivery man in the Logistics Department, his role is distributing supplies. instance SupplyDistributingRole memberOf bro#SupplementalRole instance DeliveryMan memberOf oso#OrganizationalPosition playsRole hasValue {SupplyDistributingRole} assignedTo hasValue {ouo#LogisticsDepartment} instance MrC memberOf oso#Person worksAs hasValue {DeliveryMan}

Finally, the process of processing the order for supporting commodity needs to be created. instance SupportingCommoditySupplyOrderProcesing memberOf sbpmn#Process isEnclosedInBusinessFunction hasValue bfo#SupplyOrderProcessing

In Figure 6 our exemplary process is presented. As comments, fragments of WSML code showing the use of OSO, OUO, BRO and BFO ontologies are included. Such a semantic annotation of the presented process allows for categorization of the process model (and its fragments) as well as a clear and informed assignment of roles/tasks/responsibilities. Moreover, as the entire process content is described in the machine accessible manner, the automatic processing and reasoning is possible. Therefore, employing appropriate algorithms developed within the SUPER project e.g. translation from the BPMN to BPEL process representation is possible. Moreover, business analysts are provided with new facilities for querying the process space may this be pre or post-execution. It is also possible to reason on who is responsible for what, who is doing what, what are the roles/functions associated with specific tasks. In addition, it is possible to answer questions such as i) which organizational units are responsible for carrying out given functions; ii) which organizational units are participating in a given process; and iii) which processes will be affected by changes in business process given (and how these changes will influence people, resources, etc.)? Answers to such exemplary questions may be of great importance in various situations. Such information is needed whenever the organizational structure of an enterprise is being managed and amended e.g., when the top management re-

Page 52

SBPM 2008 Proceedings

instance NotificationOfDemand memberOf sbpmn#ManualTask ... hasPerformer hasValue MrsA ... instance PaperReservation memberOf sbpmn#ManualTask ... hasPerformer hasValue MrB ...

instance PaperDelivery memberOf sbpmn#ManualTask ... hasPerformer hasValue MrC ...

Notification of demand

Paper reservation

Paper delivery

Fig. 4. Exemplary business process

structures the functional areas of the enterprise by outsourcing certain functions. Enhancing business process models with semantic descriptions enables reasoning on the process execution results, the main functionalities offered, process categorization, organizational units committed etc. Furthermore, a clear representation of the departments and/or employees interactions and their commitment in enacted processes allows for constant monitoring of their workload. Such an approach can noticeably improve the quality of business process management in the company. In case of BRO the sociological side of business organization is the clue to understand the potential use of this model. Normally, the sociological knowledge (meaning the behaviour, expectations, obligations, common interests, agent grouping configurations) is an ordinary and widespread knowledge when it comes to human beings. Yet, because of lack of experience and very impaired possibilities of real-life interactions, in case of automated information processing and machine reasoning there is a strong need of modelling such knowledge explicitly. Without it, no mechanism should be expected to know what is a customer, how a supervisor differs from any other employee or what does a stakeholder concept stand for in the context of a given organization.

7

Related Work

Within this section a short overview of the related work is provided. A detailed survey of research done in the field of formal enterprise and organization description may be found in[8]. In 1982 William E. McCarthy modelled the REA (Resource-Event-Actor) ontology [10, 11] containing only the concepts of resources, events and agents. The REA enterprise ontology is based on elements of the early REA model. Consequently theoretical background of REA comes from the field of microeco-

Page 53

SBPM 2008 Proceedings

nomics. All REA concepts and definitions are applied to the collaborative space between enterprises where market exchange occurs among two or more trading partners [12]. It is considered one of the most promising business domain ontologies, but lack of formal representation makes it useless for practice. Additionally, it is criticized for inconsistent and confusing terminology for constructs [13], and lack of clarity [14]. As a result of works conducted in the TOVE project [15] set of integrated ontologies for modelling enterprises was developed. The goal was to create shared representation of an enterprise, definition of the semantics and symbols which depict defined concepts. Four Business Ontologies (Organization, Product and Requirements, ISO9000 Quality, Activity-based Costing) and two Foundational Ontologies (Activity, Resource) were developed. Although the proposed solution is one of the most interesting and advanced in the area, the scope covered by the ontologies and their granularity is still insufficient for the needs of business process description. The e3-value ontology provides modelling constructs for representing and analyzing a network of enterprises exchanging items of economic value with each other [16]. The e3-value ontology was introduced as a tool to help explaining the concepts used to represent e-commerce ideas. For some more advanced aspects of organizations, such as strategic motivation that stem from environmental forces or factors in the environment that influence the constellation other extensions like e3forces, e3competences were developed. For the needs of business process description the level of detail proposed in e3-value ontologies is to general. It focuses on network of enterprises while our analysis is on the level of departments, roles, and business functions. Business Process Management Ontology, described in [17], allows a business analyst to define private business processes, public business processes (a.k.a. business collaborations), business entities, business objects, services that implement process activities and follow the UN/CEFACT Modelling Methodology (UMM) for business process and information modelling. For the need of business process descriptions the authors use the following constructs: business entity, task and implementation. Organization structure aspect was neglected. Although the authors emphasize that for practical usage proper instances of the constructs must be created, we find the ontology is too coarse-grained to be suitable for our purposes. A novel approach is presented in [18]. To provide further flexibility within the enterprise ontology the author suggests a contextual approach to ontology development. A context involves seven domains: purpose, actor, action, object, facility, location, and time. Created context-based enterprise ontology provides a unified view of an enterprise as an aggregation of contexts. This ontology can be specialized into task ontologies or domain ontologies to meet particular needs of enterprises, and still maintain connections of the specialized things to their contexts. From the methodological point of view this approach is the closest to our vision, and was an inspiration while designing the ontology stack for semantic description of business processes.

Page 54

SBPM 2008 Proceedings

As far as the organizational structure is concerned interesting models were described in [2–4]. Each of them represents more or less the same level of detail, the main difference being the described relations and the scope of the models. The resulting structure of OSO ontology presented in this paper is a based on the analysis and combination of solutions taken from each of them. The abovementioned initiatives provided an inspiration and foundation for developing the organizational ontologies. The structure of REA and ContextBased Enterprise Ontology are probably closest to our vision, yet they do not separate vocabulary from business process structure, which has been one of our main goals.

8

Conclusion

This paper deals with the semantic annotation of business processes in the context of the so-called Semantic Business Process Management approach. In particular, it focuses on the Organizational Structure Ontology divided into upper level organizational structure ontology and organizational units ontology. Additionally, two other ontologies, Business Functions Ontology and Business Roles Ontology are shortly discussed in order to show how the organizational structure ontology fits into the stack of organizational ontologies. The structure of the ontologies is inspired by the earlier work in the field, and extended in order to support the level of automation pursued. The solution proposed in this article is more comprehensive, provides extended flexibility when describing processes as well as adjusting the ontologies to the needs of the specific enterprise. Moreover, it is compatible with the recent emerging standards of the Semantic Web. We do not foresee any major constraints in the use of the presented models. The separation of concepts used for more advanced description of organization into subontologies is a proper solution for achieving the desired power of expressiveness. Nonetheless, the proposed ontologies should be further validated and possibly extended in order to meet the real-life challenges including more detailed levels of information . In this respect, future work will be devoted to the extension of the ontologies and their integration with other models focussed on supporting Business Process Analysis [19].

References 1. Hepp, M., Roman, D.: An ontology framework for semantic business process management. In: proceedings of the 8th international conference Wirtschaftsinformatik 2007, Universitaetsverlag Karlsruhe (2 2007) 2. Uschold, M., King, M., Moralee, S., Zorgios, Y.: The enterprise ontology. Knowl. Eng. Rev. 13(1) (1998) 31–89 3. zur M¨ uhlen, M.: Evaluation of workflow management systems using meta models. In: HICSS ’99: Proceedings of the Thirty-second Annual Hawaii International Conference on System Sciences-Volume 5, Washington, DC, USA, IEEE Computer Society (1999) 5060

Page 55

SBPM 2008 Proceedings

4. OMG: Document bmi/2006-11-02; organization structure metamodel (osm); 2nd initial submission; in response to: Organization structure mtamodel rfp (omg document bei/2004-06-05); version 0.5 november 9. Technical report (2006) 5. Malone, T.W.: A formal model of organizational structure and its use in predicting effects of information technology. Working papers 1849-86., Massachusetts Institute of Technology (MIT), Sloan School of Management (1986) 6. Fox, M., Barbuceanu, M., Gruninger, M., Lin, J.: An organization ontology for enterprise modelling (1997) 7. Boella, G., van der Torre, L.W.N.: A foundational ontology of organizations and roles. In Baldoni, M., Endriss, U., eds.: DALT. Volume 4327 of Lecture Notes in Computer Science., Springer (2006) 78–88 8. Abramowicz, W., Agata, F., Kaczmarek, M., Starzecka, M., Stolarski, P., Walczak, A.: Semantic enterprise description for the needs of business process automation. In: SemBPM2008, Finland (to be published). (2008) 9. Abramowicz, W., Filipowska, A., Kaczmarek, M., Kaczmarek, T.: Semantically enhanced Business Process Modelling Notation. In: Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM 2007) in conjunction with the 3rd European Semantic Web Conference (ESWC 2007) Innsbruck, Austria. (2007) 10. McCarthy, W.E.: The rea accounting model: A generalized framework for accounting systems in a shared data environment. The Accounting Review Vol. 57(No. 3) (July 1982) 554–578 11. Geerts, G.L., McCarthy, W.E.: An accounting object infrastructure for knowledgebased enterprise models. IEEE Intelligent Systems 14(4) (1999) 89–94 12. Geerts, G.L., McCarthy, W.: The ontological foundation of rea enterprise information systems. working paper (August 2000) Michigan State University. 13. Lampe, J.C.: Discussion of an ontological analysis of the economic primitives of the extended-rea enterprise information architecture. International Journal of Accounting Information Systems 3(1) (2002) 17–34 14. Guizzardi, G., Wagner, G.: A unified foundational ontology and some applications of it in business modeling. In: CAiSE Workshops (3). (2004) 129–143 15. Fox, M.S.: The tove project towards a common-sense model of the enterprise. In: IEA/AIE ’92: Proceedings of the 5th international conference on Industrial and engineering applications of artificial intelligence and expert systems, London, UK, Springer-Verlag (1992) 25–34 16. Gordijn, J., Akkermans, H.: Value based requirements engineering: Exploring innovative e-commerce idea. Requirements Engineering Journal 8(2) (2003) 114–134 17. Jenz, D.E.: Strategic white paper. ontology-based business process management. the vision statement; first edition november 2003 (2003) 18. Leppnen, M.: A context-based enterprise ontology. In Abramowicz, W., ed.: BIS. Volume 4439 of Lecture Notes in Computer Science., Springer (2007) 273–286 19. Pedrinaci, C., Domingue, J., Alves de Medeiros, A.K.: A Core Ontology for Business Process Analysis. In: 5th European Semantic Web Conference. (2008)

Page 56

SBPM 2008 Proceedings

Enterprise Attention Management System Darko Anicic1 , Nenad Stojanovic1 , and Dimitris Apostolou2 1

2

FZI Forschungszentrum Informatik, Haid-und-Neu-Straße 10-14, 76131 Karlsruhe, Germany ˜[email protected] FDepartment of Informatics Decision Support Systems Lab, University of Piraeus, Greece ˜[email protected]

Abstract. We present a novel approach for proactive support of user in knowledge intensive organisations. Whilst once information was a scarce resource, nowadays all kinds and qualities of information are available. However human attention has become a scarce resource which is difficult to manage and support. Our attention management system proactively supports the user in dealing with processes, activities and tasks defined by a semantically-enhanced business workflow. Moreover the user is supported in reacting on changes respecting the users’ context and preferences. The approach is based on an expressive attention model, which is realized by combining context-aware ECA rules with ontologies and an appropriate preference model. We present the system’s architecture, describe its main components and present early evaluation results. Our system is particularly deployed in a use case related to eGoverment. Nevertheless the architecture we present is general, and may be used in all kind of information and knowledge systems where handling the user attention is of an important interest.

1

INTRODUCTION

Success factors in knowledge-intensive and highly dynamic business environments include the ability to rapidly adapt to complex and changing situations and the capacity to deal with large quantities of information of all sorts. For knowledge workers, these new conditions have translated in acceleration of working performance, multiplication of projects in which they are involved and increased collaboration with colleagues, clients and partners. Knowledge workers are overloaded with potentially useful and continuously changing information originating from a multitude of sources and tools. A significant part of a knowledge worker’s day can be occupied with searching and looking for information. In order to cope with changes of the business environment, the attention of knowledge workers must be always paid on the most relevant information sources. Indeed, a basic requirement of knowledge workers is to be up to date with information while facing an information overload situation. In other words, the issue is how to select those information resources whose reading will give most benefits to the reader. Moreover, agility and proactive computer can be

Page 57

SBPM 2008 Proceedings

useful in an environment of knowledge workers with overburdened memories: The computer should know what a knowledge worker works with and show him/her relevant information before they need them, in a kind of pre-search function. According to [1], attention is defined as a ”focused mental engagement on a particular item of information”. According to [2], attention is a process of selection and selective processing, required because the brain has a limited information processing capacity. In an enterprise context, attention management refers to supporting knowledge workers focus their cognitive ability on a particular organizational task and on the information resources required to accomplish it. In particular support is required for searching, finding, selecting and presenting the most relevant and up-to-date information without distracting workers from their activities. Information retrieval systems have provided means for delivering the right information at the right place and in right time. The main issue with existing systems is that they do not cope explicitly with the information overload, i.e. it might happen that a knowledge worker ”overlooks” important information. The goal of attention management systems (AMS) is to avoid information overload and to provide notifications about new and changed, relevant information [1]. Moreover, the frequently changing environment requires not only very effective systems for alerting knowledge workers that some relevant piece of information has appeared or has been changed, but also effective recommendation how to deal with these changes. Our approach for managing attention in a business environment is not just to support receiving new relevant information proactively, but also to enable relevant reaction on this information (i.e. on a change in general). Such an action can be an already predefined workflow, but also ad-hock generated procedures according to the currently available knowledge/experience. In that sense, our approach of an enterprise Attention Management System (AMS) goes beyond informing a user proactively that something relevant has been changed, toward proactive preparing and supporting the user to react on that change. Our approach puts forward a comprehensive reasoning framework that can trigger a knowledge base in order to find out the best way to react on a change. We base such a framework on a combination of reactive, deductive, and preference rules and ontologies. The paper is organized as follows: in the second section we analyze requirements and outline a framework for an enterprise attention management system, in the third section we present the SAKE attention management model, in the fourth section we present the architecture of the SAKE attention management system encompassing various new functionalities to address relevant attentionrelated issues. We conclude by suggesting outlets for future research and development in information technology for the purpose of managing users’ attention in knowledge-intensive environments.

Page 58

SBPM 2008 Proceedings

2

Requirements for AMS

This section summarises the basic requirements for an Enterprise Attention Management system: 1. Flexible modeling of information in order to enable focusing of attention on different abstraction levels. For example, a user interested in information about pets should be alerted for new information about domestic animals. Another issue is modeling the usage of information by a community of users in order to stimulate sharing of implicit knowledge. For example, users looking for front tyre pressure must be proactively fed with the rear wheels’ pressure as most technicians are interested in both in most maintenance situations. 2. Context-awareness in order to support a particular decision making process. For example, new law about animals triggers different alerts in different regulation and business process areas. 3. Management of preferences for enabling efficient extraction of interesting information. In particular, there is a need for an expressive formalism for the description of preferences, including when to alert a user, but also how to react on an alert. Figure 1 presents the general framework of Enterprise Attention Management (EAMS) that builds on the aforementioned requirements.

Fig. 1. Enterprise Attention Management Framework Our framework is developed along 3 axes: 1. Information represents all relevant chunks of knowledge that can be found in the available information repositories and sources. In the business environment of an organization, sources of information can be both internal and

Page 59

SBPM 2008 Proceedings

external to the organization. Moreover, information can be represented either formally (e.g. using information structuring languages such as XML) or informally. Finally, information may be stored in structured repositories such as databases that can be queried using formal languages or in unstructured repositories such as discussion forums. 2. Context defines the relevance of information for a knowledge worker. Detection of context is related to the detection of the user’s attentional state which involves collecting information about users’ current focus of attention, their current goals, and some relevant aspects of users’ current environment. The mechanisms for detection of user attention that have been most often employed are based on the observation of sensory cues of users’ current activity and of the environment; however others, non-sensory based, mechanisms also need to be employed to form a complete picture of the user’s attentional state [3]. 3. Preferences enable filtering of relevant information according to its importance/relevance to the given user’s context. In other words, the changeability of resources is proactively broadcasted to the users who can be interested in them, in order to keep them up to date with new information. Users may have different preferences about both the means they want to be notified and also about the relevance about certain types of information in certain contexts. User preferences can be defined with formal rules or more informally by means e.g. of adding keywords to user profiles. Moreover, even when employing mechanisms capable of formalizing the users’ preferences, a certain level of uncertainty about users’ preferences will always remain. For this reason, dealing with uncertainty is an important aspect of attention management systems. Equally important is the way preferences can be derived: by explicitly specifying them or be learning techniques.

3

The SAKE Attention Model

This section presents an attention model which we have developed in SAKE3 project. Unlike other similar models, our attention model proactively supports the user in reacting on changes respecting the user’s context and preferences. The approach is realized by combining context-aware reactive rules, with ontologies, and an appropriate preference model. Such an expressive attention model is the basis of the SAKE Event-and-Context driven Attention Management System (ECAMS). Figure 2 presents the conceptual attention model behind SAKE. The model assumes that the interactions between users and internal information sources are logged including the business context (e.g., business process) in which the interactions happened. Some log entries can be defined as events that cause alerts, which are related to a user, a problem domain and associated to a priority level. 3

SAKE - Semantic-enabled Agile Knowledge-based eGovernment is an EU funded project (IST 027128): http://www.sake-project.org

Page 60

SBPM 2008 Proceedings

Every alert invokes actions, that can be purely informative (i.e. an information push) or executable (i.e. to execute a business process).

Fig. 2. Conceptual Attention Model

In the core of the SAKE approach we use a new form of reactive rules, i.e. ECCA (Event - Context - Condition - Action) rules; their general form is: ON event WITHIN context, IF condition DO action. Justification for using this new form of reactive rules in our attention management system is elaborated in Section 4.2. Relevant events and actions are usually triggered by interactions taking place in organisational systems, such as the SAKE workflow, Content Management System (CMS) and the GroupWare System (GWS) or by external change detectors. The later are implemented with the Change Notification System (CNS), a component that can be configured to monitor web pages, RSS feeds and files stored in file servers for any change or specific changes specified by regular expressions (e.g. new web content containing the keyword ”sanitary” but not ”pets”).

4

The SAKE Event-and-Context driven Attention Management System

Figure 3 depicts overall architecture of the SAKE ECAMS system that suits to the general EAMS framework given in Figure 1. The figure also shows other core components of SAKE, i.e. the SAKE Workflow Management System (WfM), Content Management System (CMS), the GroupWare System (GWS) and the Change Notification System (CNS). In the following, we first outline roles of

Page 61

SBPM 2008 Proceedings

SAKE components which do not belong to SAKE ECAMS, while a more detailed description of ECAMS is given through next subsections.

Fig. 3. SAKE Overall Architecture

Relevant events and actions are usually triggered by interactions taking place in organisational systems, such as the SAKE WfM, CMS and GWS or by external change detectors. The later are implemented with the CNS, a component that can be configured to monitor web pages, RSS feeds and files stored in file servers. The SAKE content management system (CMS) enables storage and provision of content by: – supporting the annotation of content with metadata as well as relations between different content items; – semi-automatic population of metadata using text mining methods; and – realizing semantics-based search that retrieves content based on both fulltext and metadata. The SAKE GroupWare system (GWS) supports information sharing and creation by: – supporting the annotation of the interactions between users; – enabling identification of communities of practice from mining their interactions and their specific vocabularies by social tagging; and – searching for experts based on their profiles as these are created explicitly and implicitly during their interaction with the system. The SAKE workflow management system (WfM) coordinates execution of users tasks in SAKE system by:

Page 62

SBPM 2008 Proceedings

– integrating GWS, CMS and ECAMS itself; – strongly supporting business context management and sharing of the actual user’s context. The SAKE Change Notification System (CNS) is a server based change detection and notification system that monitors changes in the environment which is external to SAKE. It can be configured to monitor web pages, RSS feeds and contents of file servers. Users and the administrator can create new notification queries for finding and displaying interesting changes. When creating a query, users can define if they want to monitor a web page for any change or specific changes in links, words or a selected section specified by a regular expression. Moreover, users can select a topic of interest from a list. If new web page content is added that is related to the topic or an RSS feed update contains information related to the topic, then the user is notified. CNS relies on the services of Nutch (http://lucene.apache.org/nutch/), an open source crawler, which is used for fetching and parsing HTML documents, RSS feeds as well as resources in other supported formats. In the remaining part of this section we describe the core components of the SAKE Event-and-Context driven Attention Management System. 4.1

SAKE Ontologies

Conceptual information model in SAKE is realised via ontologies. For example, ontologies are used to model change events, describe various information resources, express user’s contexts and preference rules etc. In the following, we further discuss roles of SAKE ontologies and outline their content. Preference Ontology SAKE proactively delivers information resources (e.g., different documents and files) to a user. The resource delivery is realised in a process of matching the business context on one side, and user’s preference rules on the other side (preference rules are described in Section 4.3). Relationship between the business context and user defined preferences is handled via the validIn relation in the preference ontology, Figure 4(b) (e.g., particular preference rule is validIn a certain context). The preference ontology 4(a) is typically imported by another ontology which maps its own concepts to this ontology. More specifically, by subclassing PreferredResource the importing ontology defines for which type of resources (i.e., individuals) the user can define preferences. Similarly, subclasses of ContextObject should be defined in order to indicate which type of individuals the Context consists of (i.e., the business process, activity, task, and the user). Furthermore, we differentiate between a RuntimeContext and a PersistedContext. The RuntimeContext reflects the user’s current context and changes dynamically with the user’s interactions within the system. This context may be used to track user’s behaviour in the system. However, if a user’s interaction is logged in the system as a persistent activity (e.g., the creation of a new document) the user’s current context will be persisted (using the PersistedContext).

Page 63

SBPM 2008 Proceedings

The RuntimeContext and PersistedContex are utilised by the Context Observer to extract the current business context, and hence, enable resource delivery based on that business context.

(a) Class hierarchy

(b) Class diagram

Fig. 4. Preference Ontology.

Information Ontology The Information ontology (Figures 5 and 9(a)) contains the concepts and relations about information resources for which we want to express preferences, such as documents and forum messages. On the top level we have separated the domain concepts from value types. The FiletypeValue class defines the different file types a file in the SAKE system can have. In the InformationSource sub-tree we differentiate between information sources which are of an abstract nature (such as persons), external information sources such as Web pages and RSS feeds, and information sources which physically exists in the SAKE system, such as documents, forums or e-mails. We further divided the physical information sources into CMS-specific and GWS-specific entities. This FiletypeValue class represents the file type (indicated by the file extension) of a document, for example PPT, PDF, DOC, etc. Note that one subclass of filetype can describe multiple file extensions, such as JPG can be a .jpg or .jpeg file. Log Ontology There are many sources of changes that can affect an information resource, like adding, removing, deleting a new document or starting a new discussion. The Log ontology (Figures 6(a) and 6(b)) is used for representing these changes in a suitable format. There are four subclasses of Event: AddEvent,

Page 64

SBPM 2008 Proceedings

Fig. 5. Information Ontology, Class diagram

RemoveEvent, ChangeEvent and AccessEvent. AddEvent is responsible for the creation of new events, e.g. a new document has been added to the SAKE CMS. It contains two subclasses: AddToCMSEvent, meaning the addition of a resource to the CMS and AddToParentEvent, meaning the addition of an existing child to a parent element, e.g. posting a new message to a discussion thread (Figure 7). RemoveEvent is dedicated to the deletion of the existing elements from the system, like the deletion of a document from CMS. It consists of RemoveFromCMSEvent, meaning the removal of a resource from the CMS and RemoveFromParentEvent, meaning the removal of a child from a parent element, but the child is still existent. ChangeEvent is responsible for the modification of an existing individual, e.g., the change in the name of the author of a document. It consists of: PropertyChangeEvent, meaning that some properties of an individual have changed and IndirectChangeEvent, meaning a change caused by some other event. AccessEvent is dedicated to the access of an existing individual. It represents a very broad class of events like reading a document, for which is very complicated to define the semantics clearly. For example, did someone who opened the document and closed it after five minutes, read the document or just opened, considered it as not interesting, but forgot to close it immediately? We differentiate subclasses AddEvent and RemoveEvent by addition/removal of resources to/from the CMS and by addition/removal of a resource to/from a parent/child relationship using the isPartOf property. AddToCMSEvent is fur-

Page 65

SBPM 2008 Proceedings

(a) Class hierarchy

(b) Class diagram

Fig. 6. Log Ontology.

Fig. 7. AddToParentEvent for Adding a New Event

ther differentiated by either creating a resource within the SAKE system or uploading an existing resource. For ChangeEvents, we distinguish between changes of the resource’s properties (e.g. metadata) and changes which are caused by some other event. Properties of an event are the resources the event relates to, the user who originated the event, a timestamp when the event occurred, an optional de-

Page 66

SBPM 2008 Proceedings

scription of the event and a copy of the current runtime context. In the case of ChangeEvents we add the names of the resource’s changed properties, and optionally link to another event which caused this ChangeEvent. We do not hard-code the propagation of events from child to parent, instead we define them in SWRL (Semantic Web Rule Language) rules4 , such as:

Fig. 8. Automated Event Creation with SWRL

Default rules state that the addition/removal of a child object triggers a ChangeEvent for the parent object. However, in order to be more flexible, we could also state that the modification of a specific child object also causes the modification of its parent. Note that in this way, we may use events to specify more complex events (e.g., indirectChangeEvent). Those complex events are created using SWRL rules and a number of built-in predicates supported by KAON2 . Although realised in a declarative way, Complex Event Processing (CEP) in SAKE is still limited, and it is subject of our future work. Particularly, we will continue developing declarative CEP. The advantage of such an approach is that definition of a complex event may easily be altered by changing only a logical rule.Further on, inconsistencies in CEP are handled by means of logic. Process Ontology While the other SAKE ontologies are rather general, the process ontology (Figure 9(b)) is specific w.r.t the SAKE use case scenario. The use case describes a knowledge intensive eGovernment organisation and necessities help for knowledge workers in their daily business. The process ontology describes main concepts related to various legal procedures in a municipality administration and their relationship. 4.2

Contextual Event Processing

Reactive rules (such ECA and production rules [4]) are usually used for programming rule-based, reactive systems, which have the ability to detect events and respond to them automatically. However in many cases there is a gap between current reactive rules that enable reaction to an event (change), and the reality, in which reaction is relevant only in a certain context [5]. As event-driven reactive systems act autonomously, a central issue is the ability to identify context during which active behaviour is relevant and the situation in which it is required. 4

SWRL: http://www.w3.org/Submission/SWRL/

Page 67

SBPM 2008 Proceedings

(a) Information Ontology

(b) Process Ontology

Fig. 9. Ontologies (Class Hierarchies) for the SAKE Use Case.

In SAKE, the business context is derived using a context observer. This component links to enterprise systems (such as workflows) and extracts the current business process, activity, and task the user is working on. The context describes the situation which a user is currently present in, and is utilized for derivation of information resources based on context-sensitive preferences.

Page 68

SBPM 2008 Proceedings

The business context in SAKE is formally described (see Section 4.1), which in turn allows contextual reasoning with reactive rules. In classical reactive systems [6, 7] based on Event-Condition-Action (ECA) rules, reaction (i.e., action) is triggered by an event, provided that the condition holds. Typically the condition part provides the contextual background information. However this way of expressing the context is rather limited. In our opinion, an automated reactive system needs to be capable to deal with more complex business contexts and situations, and hence needs to reason before undertaking any action [8]. This is why we introduce ECCA rules where the context is explicitly represented5 . Moreover the context is formally realized by means of ontologies, and hence allows for automated reasoning techniques to be applied. Depending on a user’s current working context (i.e., business process, activity and task), the reasoner in SAKE ECAMS automatically searches for relevant knowledge artifacts. In a nutshell of the process, the inference engine takes the user’s business context (from the workflow), and gives back relevant information resources. What is relevant to a user does not depend only on a particular business context, but also on the user defined preference rules (described in the following Section 4.3). 4.3

Preference Rules

A preference is an n-ary relation between a user, multiple resources, and a preference value. Figure 10 shows how such a preference relation is formally modeled using the preference ontology. Each preference (i.e., n-ary relation) is expressed as a deductive rule [9], represented in SWRL. Figure 11 illustrates an example of a preference rule: if userA is in the processZ, then userA has preference of value 1.0 for documents created in 2006. Among the preferred values, preferences include the business context of the user, in order to support context-awareness of the whole system (e.g., userA and processZ are related to each other by the same runtime context: ctx.

Fig. 10. Preference as n-ary relation between a resource, value, user and rule

Utilising logical rules, for expressing context-sensitive user preferences, SAKE features a very flexible preference model. One rule is used to assign different 5

the condition part in an ECCA rule is used for representing simple condition - one that requires no reasoning (as complex computation) in order to be evaluated.

Page 69

SBPM 2008 Proceedings

Fig. 11. A Sample Preference Rule Expressed in SWRL

preference values to different information resources based on relevant criteria of a particular user. Therefore every information resource may be assigned with different preference values by different preference rules (i.e., by different users and/or business contexts). Another flexibility of the SAKE preference model comes from an implicit representation of preferences. Since preference values are not pre-computed and persisted in the system, just adding one preference rule may significantly influence the whole preference model. Also adding a common preference to the SAKE preference model (i.e., a preference valid for all users) may be as easy as adding only one preference rule. Moreover updating existing resources, or adding new ones, does not mess up all previously created preference values. In this way, a user is given a great freedom to create particular preferences for particular processes, activities, tasks, and even to aggregate multiple preference values for one resource into a final score. The Preference Editor supports creation of preference rules by providing a GUI for step-wise, interactive rule development, as presented in Figure 12. The user starts with selecting what kind of resources (i.e., file, forum, workspace, email etc. that is a subclass of pref:PreferredResource) s/he wants to define a preference for. This information is specified in the information ontology (Figure 9(a)), and is represented as a variable ?res in Figure 11. The preference rule, is than, further extended narrowing down the preference criteria in several subsequent steps (possible introducing new variables). For each of these steps, SAKE reasoner is used to find out the list of possible properties or property values that are available. Further on, values entered by a user are syntactically checked out (e.g., for the data type). In this way, the Preference Editor eases the process of creating valid and consistent preferences.

Fig. 12. Preference Editor: Step-wise, interactive rule development

Page 70

SBPM 2008 Proceedings

Preference rules, created by the editor, are serialised to its SWRL representation and stored in the preference ontology. Finally, preference rules may also be removed (or updated) using the Preference Editor.

5

Conclusion and Future Work

In this paper we presented a novel approach for managing user’s attention. The approach is realised through a reactive system that manages not only alerts to a user when something has been changed, but also supports the user to react properly on that change. In a nutshell, the corresponding system is an ontologybased platform that logs changes in internal and external information sources, observes user context and evaluates user attentional preferences represented reactive rules. The presented system is currently under deployment in a real-environment. We have developed the first prototype, however results from the formal evaluation are still missing. Future work of the attention management framework, presented here, will go toward a logic based event-driven reactive system (see [8]). Such a system will be fully automated and controlled by a state-changing logic. Furthermore the system will allow new reasoning services, e.g. reasoning about conflicting business contexts and situations, as well as, causal relationships between complex events, conditions, and actions.

References [1] T.H. Davenport and J.C. Beck. The Attention Economy: Understanding the New Currency of Business. Harvard Business School Press, Cambridge, MA, 2001. [2] Jr Norton, William I and William T Moore. Entrepreneurial risk: Have we been asking the wrong question? In Small Business Economics, 2002. [3] C. Roda and J. Thomas. Attention Aware Systems: Theory, Application, and Research Agenda. Computers in Human Behaviour 22, 557–587, 2006. [4] B. Berstel, P. Bonnard, F. Bry, M. Eckert, and P. L. Patranjan. Reactive rules on the web. In Reasoning Web. Springer, 2007. [5] David Botzer Opher Etzion Asaf Adi, Ayelet Biger and Ziva Sommer. Context awareness in amit. In Active Middleware Services, 2003. [6] Norman W. Paton, F. Schneider, and D. Gries. Active Rules in Database Systems. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1st edition, 1999. [7] Jennifer Widom and Stefano Ceri. Active Database Systems: Triggers and Rules For Advanced Database Processing. Morgan Kaufmann, 1st edition, 1996. [8] Stojanovic N Anicic D. Towards creation of logical framework for event-driven information systems. In To appear in: 10th International Conference on Enterprise Information Systems, 2008. [9] J. W. Lloyd. Foundations of Logic Programming. Computer Science Press, 1989.

Page 71

SBPM 2008 Proceedings

Event-driven Reactivity: A Survey and Requirements Analysis Kay-Uwe Schmidt1 , Darko Anicic2 , and Roland St¨ uhmer1 1

2

SAP AG, Research, Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe ˜http://www.sap.com FZI Forschungszentrum Informatik, Haid-und-Neu-Straße 10-14, 76131 Karlsruhe ˜http://www.fzi.de

Abstract. Despite the huge popularity of event processing nowadays, there is a big gap between the potential usefulness of event-driven processing and the current state of the practice. One of the main reasons is the lack of a comprehensive conceptual model for the event-triggered reactivity and the corresponding framework for its management. In this paper we survey the current state of the art in event-driven architecture with special focus on event and action processing. We describe the prerequisites of a completely novel conceptual model for describing reactivity that is more close to the way people react on events: based on the ability to identify the context during which active behavior is relevant and the situations in which it is required. This approach opens a completely new view on the event processing as the way for managing a very valuable knowledge asset of every enterprise - knowledge how to react (make decisions) in event-driven situations.

1

Introduction

Event-driven processing becomes ever important in various application domains, ranging from traditional business applications, like supply-chain management, to the entertainment industry, like on-line gaming applications. The market value should increase tenfold by 2010 and should reach something like $4bn in total (source: IBM). The most relevant market research companies, like Gartner or Forrester3 predict the key role of even-driven processing for making business more agile. Indeed, the main benefit of ”eventizing” business systems is that event processing introduces a kind of reactive dynamics in the system, that enables active responding on signals sensed/derived from the context (internal, external), which the system is functioning in. Obviously, such kind of reactivity, which we call event-triggered reactivity (EtR), opens great opportunities for system/process improvements. However, despite considerable research efforts put in this domain, the current development is just a top of the iceberg regarding the theoretical usefulness of 3

cf. Forrester research: ”CEP (complex event processing) Adoption Is Broader, Deeper, And More Business-Driven Than IT May Expect”, January 31, 2008

Page 72

SBPM 2008 Proceedings

event processing. One can find many causes for this ”problem” (like lack of usable tools, editors, standards, ...) but in the nutshell of the problem is a kind of the deficiency in dealing with the ad-hoc nature of events, i.e. unpredictable (but controlled) appearance of events. Unpredictability means that, for example, we don’t know in advance when an event will be issued, but we know that such an event can appear. In that sense, we usually don’t know exactly, in advance how we will react on an event, but we know that we will react. Indeed, we design an event so that it triggers reaction, but we react dependently on other circumstances (e.g. whether a server went down during working hours or not). In fact, an event triggers reaction and these ”other circumstances” determine the reaction. More interestingly, we can react on the same event in different ways, since these ”other circumstances” are different. Therefore, the main problem in current approaches is that the level of abstraction used in representing events and conditions is too low. It requires too much puzzling (of events) without having any more abstract commonality between events (analogy is using only the form of puzzles as the feature to find the next suitable puzzle: really, it is a hard work if all puzzles are black and every puzzle has unique form). If the events we are dealing with are more complex, the possibility/easiness to build useful applications is higher. On the other side, people are processing events in another (more abstract) way: they are reacting on situations according to the context. A central issue in our reactivity (and in general in reactive and proactive systems) is the ability to identify the context during which active behavior is relevant and the situations in which it is required. The concept of situation is an extension of the concept of composite event in its context awareness capability; it results in additional expressive power, flexibility and usability. The main point is that puzzling events (and actions) in complex structures can be done now by using this abstract description as an additional feature, which certainly alleviates the whole process. In this paper we provide a survey and requirements analysis for handling the event triggered reactivity. We distinguish the analysis between a non-logic and logic-based view on handling the event triggered reactivity. The non-logic view does not consider formal (logical) representation of elements in reactive rules. On the other hand, the logic-based approach follow the line of thinking that semantics of complex relationship in both a single reactive rule and ruleset should be described formally. In this way, a control mechanism for an automated execution in reactive systems is established by means of logic. Furthermore we distinguish the analysis between event processing (i.e., change detection) and action processing (i.e., reaction on change). Sections 2 and 3 recap the state of the art (for event and action processing, respectively) in event-triggered reactivity. Section 4 derives requirements for handling Event-triggered Reactivity. Section 5 gives an outlook of our future plans.

Page 73

SBPM 2008 Proceedings

2

Event Processing

Complex Event Processing (CEP) and Event Stream Processing (ESP) Complex Event Processing and Event Stream Processing (ESP) are two fields of research concerned with the handling of events. Traditionally the fields tried to solve different problems in event processing using different approaches. The next paragraphs will outline these approaches, as they are seen e.g. by David Luckham in [1] and by others. Events may happen in a stream or in several streams, a cloud. The field of ESP is concerned with extraction of events from a stream. Thus ESP handles events that are totally ordered by time. Further emphasis of ESP lies on efficiency for high throughput and low latency. Processing is done by analyzing the data of the events and selecting appropriate occurrences. Long-running queries produce results regularly; an analogy may be drawn to signal processing. CEP, on the other hand, is more focused on complex patterns of events. To detect these patterns CEP takes more time and memory than ESP. CEP is concerned with clouds of events, which yield only a partial temporal order of events. Other partial orders of interest for CEP are causality, association, taxonomy, ontology. Rather than to signal processing, an analogy may be drawn to higher level situational inferencing, in comparison to ESP. However, because CEP and ESP nowadays adopt each others approaches, the two worlds become mingled and sources as [2] declare them one and the same field. 2.1

Non-logic-based Approaches

Early event specification languages were developed for active databases [3]. They use complex event specifications to facilitate database triggers which do not only listen to simple events but observe complex combinations of events until the trigger procedures are executed. Simple events carry a type, their occurrence time and possibly other parameters that can be used in data analysis to help in detecting event patterns or be part of a computation after detection. Building on the event types one can create complex nested expressions, using operators like And, Or, Sequence, and others that have been proposed since the start of CEP in the 1990s. Complex event specifications are patterns of events which are matched against the streams of events that occur during the run-time of the system. These patterns consist of simple event types and event operators. Simple events are the basic events the system can detect. Complex events are detected from occurrences of one or more of them. All simple events have a simple event type, which for a database application might be insert, update and delete. The types are used as placeholder in event patterns. Event patterns are structured by event operators. A given operator might have several event types as arguments and e.g. stipulate that the constituent events must occur in sequence. An event detector for the given pattern functions as a stream pattern matcher and listens for events that satisfy the type

Page 74

SBPM 2008 Proceedings

constraints and together satisfy the semantics of the given operator, e.g. occurred in sequence. Many operators were proposed in the past and the following paragraphs discuss several event pattern languages and their operators. Usual operators offered by many languages include disjunction, sequence and accumulation. One early active database system is HiPAC [4]. It is an object-oriented database with transaction support. HiPAC can detect events only within a single transaction. Global event detectors are proposed which detect complex events across transaction boundaries and over longer intervals, but no further details are given. Ode [5] is another active database system with a language for the specification of event expressions. The language is also referred to as Compose. Ode proposes several basic event operators and a large amount of derived operators for ease of use and shorter syntax. The last of the classical event specification languages discussed here is Snoop [6] and its successor SnoopIB. Snoop provides the well known operators And, Or, as well as Sequence. The remaining operators are: Not, Any, A, A*, P, P* and Plus. Early work on Snoop views events as having instantaneous occurrences. This also holds true if an event is complex and its constituents span an interval of time. As a result the time of detection is used for the occurrence, instead of the interval from the start of the first constituent event to the end of the last constituent event. Consideration of only the time of detection is termed detection-based semantics. It poses problems with nested sequences as pointed out in [7]. Interval-based semantics for Snoop is called SnoopIB and was first published in 2006 [8]. Selection and consumption of events define which occurrences participate in a complex event. Both terms are an integral part of the semantics of an event definition. Selection defines the choice of events if there are more than one event of a required type that have not yet been consumed. Consumption is concerned with the deletion of events when they cannot be part of further complex events. Other approaches to event pattern languages include statements reminiscent of SQL. Two examples are StreamSQL4 and Continuous Computation Language CCL5 . Queries in these languages match patterns in streams instead of database tables. Queries are long-running and produce incremental results in contrast to SQL queries. In CCL sliding windows are supported, joins are possible to form complex events and patterns may be specified using the operators conjunction, disjunction, sequence and negation. All operators can only be applied to bounded windows of events. Complex events have to adhere to SQL schemata which prohibits nested sets, for example an events that includes a previously unknown number of constituents. Although the well known syntax of SQL might help with the adoption of these languages, a seamless integration of an action part seems hard to accomplish. None of these approaches so far interact with the business vocabulary. They also do not consider the context of events and the relationship between events and actions. 4 5

http://streambase.com/developers/docs/latest/streamsql/index.html http://www.coral8.com/system/files/assets/pdf/5.2.0/Coral8CclReference.pdf

Page 75

SBPM 2008 Proceedings

Many of the aforementioned event languages belong to their respective database management system, or prototype thereof. Three of them are described here, which have noteworthy implementation details: The Ode approach conducts complex event detection by using automata. SAMOS uses colored Petri nets. Sentinel uses a graph based approach. Complex event detection in Ode [9] is implemented using automata. Input for the automata is a stream of simple events. Ode thus transforms complex event expressions into deterministic finite automata. For sub-expressions which are complex events themselves, the process is done recursively. Atomic simple events are ultimately represented as automata of three states; a start state, an accepting state, entered upon detection of the simple event occurrence, and a non-accepting state, entered upon detection of any other simple event. Apart from providing the implementation, automata are a convenient model to define semantics of complex event operators. A downside of automata is that an automaton cannot accept overlapping occurrences of the same complex event. Also event parameters pose a problem. They are either stored outside of the automaton, or the automaton is increased greatly in the number of states to accommodate the different parameters and possible values thereof. Complex event detection in SAMOS [10] is implemented using Petri nets. Each primitive event type is represented by a Petri net place. Primitive event occurrences are entered as individual tokens into the network. Complex event expressions are transformed into places and transitions. Where constituent events are part of several expressions, duplicating transitions are used to connect the simple event with the networks requiring it. This results in a combined Petri net for the set of all event expressions. Petri nets, like automata provide a model of the semantics of event operators. Also the detection of overlapping occurrences is possible. Event parameters are stored in tokens and flow through the network. Although the tokens are individual, there is no mechanism to deterministically choose a token if there are more than one in a single place. Sentinel [11] is an active object-oriented database implementing complex event detection for the Snoop operators. Event detection follows a graph based approach. The graph is constructed from the event expressions. Complex expressions are represented by nodes with links to the nodes of their subexpressions, down to nodes of simple events. Event occurrences enter the bottom nodes and flow upwards through the graph, being joined into composite occurrences. The graph is a directed acyclic graph and generally does not form a tree for two reasons: nodes may have several parents, when their represented expression is part of more than one complex events, and secondly there is no single root node, when there is no overarching, single most complex event. A possibly conceived drawback of Snoop compared to the previously mentioned implementations is that the data structures of Snoop do not represent and even clarify the semantics of the event expressions. The logic of Snoop is hidden in the implementation of each graph node. However the semantics of Snoop is defined externally, using event histories and describing the operators as mappings from simple event histories to complex event histories. Furthermore Snoop defines the selection and

Page 76

SBPM 2008 Proceedings

consumption of simple events for the concurrent detection of overlapping complex events. The four alternative definitions, Recent, Chronicle, Continuous and Cumulative context were described earlier. 2.2

Logic-based Approaches

In order to capture relevant changes in a system and respond to those changes adequately, a number of logic-based reactive frameworks have been proposed. It is a challenge to ensure that a reactive system handles changes (events) properly and in an automated manner. By handling changes it is meant that a reactive system undertakes certain actions (reactions) which can be seen as an act of change propagation. In general, an action changes the state of the system or triggers a new event (more details about actions are given in Section 3, particularly Section 3.2). Therefore it is a question how to effectively control the whole reactive system, i.e. how machines can keep executing certain activities, ensuring at the same time the system consistency. In order to achieve this goal, logic-based reactive approaches combine a reactive system (e.g., Event-Condition-Action system) with deductive capabilities of a particular logic. IBM has been developed an event processing tool available in IBM Tivoli Enterprise Console. The engine is capable to processes complex events and executes Event-Condition-Action rules. The Prolog programming language [12] is used as an underlying formalism for specifying events, event filters, and actions. A Logic Programming (LP) routed approach for dealing with events has also been proposed in [13]. More precisely, deductive rules are utilised for creating implicit events. Motivation to use datalog-like rules, extended with stratified negation was justified there by a number of reasons. First, rules serve as an abstraction mechanism and offer a higher-level event description. Rules allow for an easy extraction of different views of the same reactive system. Rules are suitable to mediate between the same events differently represented in various interacting reactive systems. Finally, rules can be used for reasoning about causal relationship between events. In [14] a homogeneous reaction rule language was proposed. This approach combines complex event and action processing, formalisation of reaction rules in combination with other rule types such as derivation rules, integrity constraints, and transactional knowledge updates. Motivation to use logic in reactive systems is also justified there with the need to correctly and effectively process the eventbased behavioural and semantics of reaction rules. However one drawback of this approach is the query based complex event processing (the same issue holds for [13]). In order to simulate active behaviour of ECA systems with passive Logic Programming based systems, the complex event processing in above mentioned approaches, is realised by frequently issued queries. For instance, a complex event pattern is encoded as a query and issued periodically. If such a query retrieves an answer, the system identifies that as an occurrence of a corresponding complex event. The complex event is than used for selecting ECA rules that need to be executed. The query based complex event processing realised with passive LP systems are not capable to identify complex events as soon as they emerge, but

Page 77

SBPM 2008 Proceedings

at the time when a corresponding query is processed. This issue may have certain implications with respect to the intended semantics of complex ECA rules.

3

Action Processing

Although event processing is a major part in event-triggered reactivity there is more to it: actions. Action processing is the task of executing actions triggered by events in well-defined contexts and situations. This section deals with non-logic and logic-based approaches of triggering actions caused by events. 3.1

Non-logic Based Approaches

Many active database systems not only specify an event language but also a reaction rule language. Reaction rules such as Event-Condition-Action (ECA) rules complement the event specification with a condition to be evaluated upon event occurrence and a corresponding action to take. The term ECA rule was first used in conjunction with the HiPAC active database [15]. ECA rules are a generalization of several methods to achieve active behavior, such as triggers and production rules, which had been in prior existence but treated separately. The ECA rule approach divides the rule execution in three parts, event, condition and action handling. The parts are processed concurrently but work with different input. Event processing deals with transient input, i.e. the events. Although events are objects, they are usually not made persistent but are used in an online, real-time fashion to deduce complex observations and thereby consume the less-refined input. The output from the event detection is knowledge about complex distributed incidents happening in a system. This knowledge incorporates the information from individual events in an accumulated fashion. Conditions, on the other hand, deal with persistent data or knowledge. They may be viewed as queries to a database or a knowledge base. Although the outcome of conditions may change over time, the condition evaluation generally deals with long-lived data, which unlike events may not be time-dependent. Many reaction rule languages have been proposed in the past. Not all obey the separation of event, condition and action specifications. Computational issues have been identified early. Large amounts of memory and computational effort may be wasted on the detection of events which are subsequently discarded when corresponding conditions are not met. This led many language designers to dilute the event and condition parts. Contrary to a declarative approach it is then up to the rule author to revise events expressions for run-time efficiency. Ode [5] for example, promotes so-called EA rules, instead of ECA rules, where the conditions are folded into the event specification. This is done by mixing event expressions with filters. These filter predicates can impose conditions on events in order to discard occurrences early. Thereby the deleted occurrences do not use further resources or become part of complex events which will not be needed.

Page 78

SBPM 2008 Proceedings

Similarly the logical language ADL [16] has (EC)*A-rules. Like the event masks in Ode the language tries to achieve finer granularity by mixing event and condition specifications. Production systems execute rules also termed productions based on the evaluation of some conditions. The most often used algorithm in production systems is RETE. RETE is designed by Charles Forgy and described in [17]. It is a forward-chaining algorithm for evaluating production rules (PRs)6 . Production rules are traditionally used in conjunction with a working memory. The working memory is a potentially large set of objects or values or objects which may be referenced in the conditions of rules. Actions are fired when a condition becomes true. However, conditions can be expensive to evaluate; a large working memory requires a lot of elements to be taken into consideration, and complex conditions require nested checks to be performed. Once a single element in the working memory is added, changed or deleted, the conditions of many rules may change their outcome. In the worst case every rule must be reevaluated. The RETE algorithm remedies this situation by introducing state-saving of the evaluation process between changes to the working memory. The condition evaluation needs not to be fully recomputed. This is accomplished by dividing the conditions into a hierarchical network of nodes, each doing a single comparison, filter operation, join, etc. Every node has a so-called memory which stores the objects that fulfill the constraints of its node. When an object is changed, the network does not need to be completely refilled, but only the changed object is re-fed into or removed from the network. A classic RETE network is divided into two parts; the first, called the alpha network, contains nodes with one input edge. These nodes perform filter operations using single conditions or constraints. The second part, the beta network, contains nodes with two input edges, joining objects from two subordinate nodes. A third type of node exists that models the top nodes. The rule actions are attached to these nodes. The Rete algorithm has two successors: Rete II and III but they have not been published. There are other optimized algorithms based on Rete, TREAT [18] and LEAPS [19] being two examples. Variations on Rete are implemented in many current rule engines. 3.2

Logic Based Approaches

The action part in reaction rules may additionally be described in a formal way (using a particular logic). The formal description, does not help only in controlling the execution of actions, but also allow for reasoning over complex actions7 . A homogeneous reaction rule language [14] is a language for extended ECA rules (not only for CEP) implemented in a logic framework. Moreover the lan6 7

Production rule (PR) is also called a condition-action (CA) rule. Complex actions in general case may implement non-trivial procedures such as business workflows.

Page 79

SBPM 2008 Proceedings

guage is extended with Reaction RuleML, as a platform independent rule interchange format, and rule serialization in XML. The specifications of event, condition and action are strictly separated. More precisely rules are expressed as tuples (T, E, C, A, P, EL), consisting of T time, E event, C condition, A action, P post condition and EL contingency action, ”else”. Parts might be left blank, i.e. always satisfied, stated with ” ”, e.g., (T, E, , A, , ). Blank parts might be completely omitted, leading to specific types of rules, e.g. standard ECA rules: (E, C, A), or extended ECA rules with post conditions ECAP: (E, C, A, P). Event specifications of the homogeneous reaction rule language follow the Snoop [20] operators, redefined with an interval-based semantics. Different consumption policies are mentioned but do not seem to adhere to the Snoop consumption modes Recent, Chronicle, Continuous and Cumulative. The need to declaratively describe the action component in an ECA rule has also been recognised in [21]. Particularly Calculus of Communicating Systems (CCS) [22] was chosen to formally specify complex actions, and reason about their behavioural aspects. As a part of the Process Algebra family, CCS is suitable for the high-level description of interactions, communications, and synchronizations between a collection of concurrent processes, and hence an appropriate mechanism for reactive systems in general. Although CCS is by no means powerful formalism, its use in practical world is still limited. There remains a huge gap between the model and the code, i.e., between the specification of desired behaviour and the program that implements it [23].

4

Requirements for Handling Event-triggered Reactivity

Based on the survey of state-of-the-art in event-triggered Reactivity we derived several challenges as requirements for future systems leveraging the full potential of event-triggered reactivity. 4.1

Non-logic-based Requirements

Table 1 shows a summary of todays open issues in non-logic-based event processing. Furthermore, Rete was designed for evaluating production rules (CA rules) only. Considering ECA-like rules, the event detection also needs to be considered. ECA rules are triples of event, condition and action specifications. The rules are fired, when the corresponding event has occurred, only if the condition is fulfilled. The event may be a complex event specification. Instead of managing events and conditions separately, the two should be integrated into the Rete network, extending it for temporal data and therefore event processing. This has been proposed in [24] but no results have been published. Events are manifested in first class objects. Objects provide a straight-forward facility to store parameters and other data about the event, and propagate them through the detection process. To process events, Rete could be extended with new nodes that handle events instead of working memory elements. Events may be filtered and joined according to event specifications (similarly as working

Page 80

SBPM 2008 Proceedings

Table 1. Open issues in non-logic-based event processing Technology

Open Issues

References

HiPAC

- detection restricted to a transaction - only detection-based semantics - no notion of contexts and situations

[4]

Ode, Compose

- non-declarative mix of event and condition [5] - automata do not detect simultaneous complex events of one type - automata cannot easily handle event parameters - only detection-based semantics - no notion of contexts and situations

SAMOS

- no clear strategy for event consumption - only detection-based semantics - no notion of contexts and situations

Snoop, SnoopIB - missing integration of actions - no notion of contexts and situations

[10]

[20, 11, 8]

StreamSQL,

- not extensible for actions, ECA

CCL

- detection only within (predefined) windows - no notion of contexts and situations

ADL

- non-declarative mix of event and condition [16] - no notion of contexts and situations

memory elements are filtered and joined according to the condition specification). Complex events and complex conditions may be joined to fire rule actions on activation of the join node. The integration has several advantages. No separate data structures are needed for graph based event detection and the Rete network. Also computation cycles and memory is saved by consuming events earlier, when corresponding conditions are not fulfilled: Conditions have to be positively evaluated during the detection interval of an event. Therefore when a condition is not satisfied, no constituent events need to be collected for that event. Such an implementation retains the separation of event, condition and action in a purely declarative language but benefits from a resource-saving internal execution. Mixing events and conditions on the language level may be supported, if needed. This allows for events that are masked by a condition, such as the mask construct in the ODE language [9] or (EC)*A rules in the ADL language [16] (see Table 1). Instead of joining highly complex events and conditions this is done at arbitrary levels of the network. Such masked events do not occur while their associated condition expression is not fulfilled. Furthermore, mixing event nodes and condition nodes enables conditions to see constituent event occurrences and

Page 81

SBPM 2008 Proceedings

include them in their evaluation, i.e. join operation. This way the condition part of a rule can be dependent on the occurrences detected in the event part. 4.2

Logic-based Requirements

Event-condition-action and production rules are considered as an appropriate form of rules for programming systems which need to detect changes and respond on them automatically. However in general case, their use may be very unpredictable with respect to their intended semantics [25]. In general case, execution of an event may trigger other events, and these events may trigger even more events. There is neither guarantee that, such a chain of events will terminate, nor that states (through which a reactive system passes) are valid, i.e. termination problem. Further on, two reactive rules with the same execution priority may lead the system to two different states of the whole system. The system cannot be in two states at the same time. Therefore a rule base needs to be confluent (i.e., two rules triggered in an initial state lead the system, not to two, but to a single final state, regardless of the order which any subsequent simultaneously triggered rules are selected for firing). The next issue is the rule ordering (i.e., two rules may produce different effects if the first rule is scheduled before the second and vice versa). Termination, confluence, ordering, and similar issues have been recognised and extensively discussed in the area of Active Databases [3]. Currently logic-based approaches lack a comprehensive framework capable to deal with these issues. Apart from classical concepts in event-triggered reactive systems (i.e., events, conditions and actions), those systems should also consider new notions - situations and contexts. In many cases there is a gap between current reaction rules that enable reaction to an (atomic or complex) event, and the reality, in which reaction is relevant only in a certain context in response to patterns over reaction histories [26]. As event-driven reactive systems act autonomously, a central issue is the ability to identify that context during which active behaviour is relevant and the situation in which it is required. One of advantages of logic-based approaches for handling EtR is (automated) reasoning service. However this very important feature is limited on reasoning over one component of reactive rules, i.e. either on events [13], conditions, or only on actions [21]). An appropriate formalism for expressing all components of reactive rules (i.e., events, conditions, actions, but also situations and contexts) is missing. Such a formalism would allow for reasoning over events, condition and actions uniformly as well as discovering new relationships between these constructs w.r.t a given situation and context. Further on, reactive systems are state-changing systems. Hence instead of a logic that may be used only for reasoning in one particular state, appropriate EtR processing necessitates a logic for state-changing reasoning. The purpose of such a logic is to control statechanging action execution, keeping a reactive system always in a consistent state. By executing reactive rules, the system changes its states. In this transition, every state in which the system enters, needs to be a legal state. However if the inference engine, searching for a possible execution path, enters to an illegal state

Page 82

SBPM 2008 Proceedings

such a state-transition should be rolled back. In this way, automated execution of reactive systems should be also controlled in an automated manner. In this respect an appropriate logic should be used in implementation of such advanced reactive systems. 4.3

Vision: Event-triggered Reactivity

We envision an holistic approach: Event-driven Reactivity. The unique handling of the different constituents of an event-driven architecture namely events, actions, conditions, contexts and situations will support the realization of next generation efficient and manageable event-driven (reactive) applications. It will firstly decrease the complexity of setting-up/evolving event-driven applications, that nowadays requires lots of manual work, especially in defining what an event is; secondly increase the benefits (added value) of such applications, which are currently constrained on the complex monitoring of events; and thirdly open new possibilities to apply them in highly dynamic and distributed environments. This vision will be realized through the following set of requirements: – Efficient modeling of the sense-and-respond (reactive) nature of a system, especially its contextualization – Comprehensive management of the reactivity life cycle of a system, including automatic discovery of relevant situations, efficient detection of events and reasoning about actions – Efficient implementation of the reactivity life cycle management In fact, we argue that the ECA (event-condition-action, such as it is) model is too simple presentation of the (intelligent) event processing nature which results in the already mentioned insufficiencies of event processing applications. Additionally we argue that the role of an efficient context detection process is inevitable for the efficient event processing and is totally neglected in the literature. Consequently, we argue that a unified mechanism for formal representation of all phases in the reaction cycle is needed for efficient and complex event processing [27]. In fact, we can go a step further and say that by using a richer conceptual model for describing reactions on events, we are not any more talking about simple processing of events, but rather about the management of a very valuable knowledge asset of every enterprise (system), i.e. knowledge howto react (make decisions) in event-driven situations8 . 8

Note that traditional ECA rules are not very suitable for the description of knowledge assets since they describe only a part of relevant knowledge. Indeed, if we consider a rule ”ON three servers clashes within one hour IF during workhours DO rescue”, then it codes just the ”basic” knowledge, or the simplest knowledge related to the particular situation. Much more interesting would be rules with more details, like ”ON three servers clashes within one hour IF during workhours and already tried methods are rescue#1 before rescue#2 DO rescue#3”, which can be provided by our model. Additionally, the rules are too coarse grained to be efficiently reused.

Page 83

SBPM 2008 Proceedings

Fig. 1. Gartner view on context: The Next Step for Software and Communications Architectures. Note that having context as a first class citizen in the event processing is currently completely missing in the literature for event processing. Nevertheless, context-based event processing is the next ”big thing” and should shape the future of the computing, as given in the recently issued Gartners visionary view, depicted in Figure 1. The graphics estimates Context-Driven Architecture (CoDA) as the most promising paradigm that will extend SOA. Reasoning about situations and context opens new possibilities for eventtriggered reactivity. If we would have situations as formal logic models, then some very interesting reasoning services can support the whole event processing. For example, we can define two situations as conflicting to each other and try to avoid running the whole system in such a state. The system can check formally the consistency of the system and backtrack if a conflict (meaning inconsistency in the system) is to appear. It can help us to optimize reactions on situations. Another service would be the synchronization of situations if we consider that two or more reactions will run in parallel, which is a quite natural assumption in the rich-event systems.

5

Future Work

In the future we intend to develop a new conceptual model and architecture of event-triggered reactivity (EtR) that will resolve drawbacks of existing approaches for modeling reactivity, by introducing novel concept (situation and context) and its formal, logic-based representation. Moreover we will develop a model for managing the whole life cycle of EtR, including: a) Language for

Page 84

SBPM 2008 Proceedings

modeling EtR concepts (e.g. situations, context), user-friendly editor based on pattern modeling metaphor, as well as methods for ensuring the consistency9 of such a rule base and its interoperability with other reactive systems; b) New methods and tools for the automatic discovery of complex event and situation patterns from stream data by taking into account their evolution as well; c) New algorithms for scalable ECA reasoning, based on the selected logic and its implementation in a new reasoning engine that will serve as the event-, conditionand action-handler in a reactive system. Furthermore we plan to realize, test and refine an integrated software framework for the management of EtRs life cycle, containing elements of the distributed event processing, that can be easily deployed in the selected legacy landscapes. Finally we aim the Development of use cases, their implementation, testing and evaluation in real-world pilot studies in order to validate proposed model and framework.

References [1] David C. Luckham. Whats the difference between esp and cep? Online Article, August 2006. [2] Tim Bass. Mythbusters: Event stream processing versus complex event processing. In DEBS ’07: Proceedings of the 2007 inaugural international conference on Distributed event-based systems, pages 1–1, New York, NY, USA, 2007. ACM. [3] Norman W. Paton and Oscar D´ıaz. Active database systems. In ACM Comput. Surv. ACM, 1989. [4] Dennis McCarthy and Umeshwar Dayal. The architecture of an active database management system. In SIGMOD ’89: Proceedings of the 1989 ACM SIGMOD international conference on Management of data, pages 215–224, New York, NY, USA, 1989. ACM. [5] Narain H. Gehani, H. V. Jagadish, and Oded Shmueli. Composite event specification in active databases: Model & implementation. In VLDB ’92: Proceedings of the 18th International Conference on Very Large Data Bases, pages 327–338, San Francisco, CA, USA, 1992. Morgan Kaufmann Publishers Inc. [6] Sharma Chakravarthy, V. Krishnaprasad, Eman Anwar, and S. K. Kim. Composite events for active databases: Semantics, contexts and detection. In Jorge B. Bocca, Matthias Jarke, and Carlo Zaniolo, editors, 20th International Conference on Very Large Data Bases, September 12–15, 1994, Santiago, Chile proceedings, pages 606–617, Los Altos, CA 94022, USA, 1994. Morgan Kaufmann Publishers. [7] Antony Galton and Juan Carlos Augusto. Two approaches to event definition. In DEXA ’02: Proceedings of the 13th International Conference on Database and Expert Systems Applications, pages 547–556, London, UK, 2002. Springer-Verlag. [8] Raman Adaikkalavan and Sharma Chakravarthy. Snoopib: Interval-based event specification and detection for active databases. Data Knowl. Eng., 59(1):139–165, 2006. [9] N. H. Gehani, H. V. Jagadish, and O. Shmueli. Event specification in an active object-oriented database. SIGMOD Rec., 21(2):81–90, 1992. 9

Consistency of a rule base assumes that a rule base does not contain any kind of anomalies like inconsistent, redundant or circular rules.

Page 85

SBPM 2008 Proceedings

[10] Stella Gatziu and Klaus R. Dittrich. Detecting composite events in active database systems using petrinets. In Proc. Fourth International Workshop on Active Database Systems Research Issues in Data Engineering, pages 2–9, 1994. [11] Sharma Chakravarthy. Sentinel: An object-oriented dbms with event-based rules. In Joan Peckham, editor, SIGMOD ’97: Proceedings of the 1997 ACM SIGMOD international conference on Management of data, pages 572–575. ACM Press, 1997. [12] Michael A. Covington, Donald Nute, and Andr´e Vellino. Prolog programming in depth. Morgan Kaufmann Publishers Inc. San Francisco, CA, USA, 1987. [13] Franois Bry and Michael Eckert. Towards formal foundations of event queries and rules. In Second Int. Workshop on Event-Driven Architecture, Processing and Systems EDA-PS, 2007. [14] A. Paschke, A. Kozlenkov, and H. Boley. A homogenous reaction rules language for complex event processing. In International Workshop on Event Drive Architecture for Complex Event Process, 2007. [15] U. Dayal, A. P. Buchmann, and D. R. McCarthy. Rules are objects too: A knowledge model for an active, object-oriented databasesystem. In Lecture notes in computer science on Advances in object-oriented database systems, pages 129– 143, New York, NY, USA, 1988. Springer-Verlag New York, Inc. [16] H. Behrends. An operational semantics for the activity description language adl. Technical report, Universit¨ at Oldenburg, June 1994. Technical Report TR-ISAIS-94-04. [17] Charles L. Forgy. Rete: a fast algorithm for the many pattern/many object pattern match problem. Artificial Intelligence, 19:17–37, 1982. [18] D.P. Miranker. TREAT: a new and efficient match algorithm for AI production systems. Morgan Kaufmann Publishers Inc. San Francisco, CA, USA, 1990. [19] Don Batory. The leaps algorithms. Technical report, Austin, TX, USA, 1994. [20] Sharma Chakravarthy and D. Mishra. Snoop: An expressive event specification language for active databases. Data Knowl. Eng., 14(1):1–26, 1994. [21] Erik Behrends, Oliver Fritzen, Wolfgang May, and Franz Schenk. Combining eca rules with process algebras for the semantic web. In RuleML, 2006. [22] Milner R., editor. Calculus of Communicating Systems. Theoretical Computer Science, 1983. [23] Wing J.M. Faq on pi-calculus. In Microsoft Internal Memo, 2002. [24] Bruno Berstel. Extending the rete algorithm for event management. In Proc. Ninth International Symposium on Temporal Representation and Reasoning TIME 2002, pages 49–51, Washington, DC, USA, 7–9 July 2002. IEEE Computer Society. [25] Michael Kifer, Arthur Bernstein, and Philip Lewis. Database Systems - An Application-Oriented Approach. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2nd edition, 2006. [26] Asaf Adi, Ayelet Biger, David Botzer, Opher Etzion, and Ziva Sommer. Context awareness in amit. In Active Middleware Services, 2003. [27] Anicic D. Stojanovic N. Towards creation of logical framework for event-driven information systems. In To appear in: 10th International Conference on Enterprise Information Systems, 2008.

Page 86

SBPM 2008 Proceedings

A Toolkit For Business Process Owners to Capture Early System Requirements Ken Decreus, Frederik Gailly, Geert Poels Faculty of Economics and Business Administration, Ghent University {ken.decreus, frederik.gailly, geert.poels}@ugent.be

Abstract. Semantic Business Process Management (SBPM) raises Business Process Management (BPM) from the IT level, where it mostly resides now, to the business level, where it belongs. SBPM provides a rich ontological description of both enterprise and process aspects, and aims to support business process modellers by means of SBPM modelling tools. Unfortunately, no explicit support is foreseen to capture early system requirements coming from the business process owner. To meet this need, we propose a toolkit approach and provide a mapping algorithm to semi-automatically insert the acquired business knowledge in the SBPM modelling environment. Keywords: business process owner, early-phase requirements engineering, requirements elicitation toolkit, i* modelling framework, BPMO.

1

Introduction

Since the 1980s, information systems development methods have been extensively discussed in literature [1]. During the first phase of these development methods, i.e. requirements analysis, Conceptual Modelling (CM) techniques are frequently employed to capture the meaning of information by constructing computer-based symbol structures [2]. One of the current problems [3] in the field of CM is the gap between the work on enterprise ontologies (e.g. TOVE [4], Enterprise Ontology [5]) and the workflowcentric view on business processes (e.g. BPEL [6]). Enterprise ontologies describe the conceptual structures of an enterprise without considering how these models are executed in production systems. On the other hand, workflow-centric process representations capture business activity sequencing and other execution flow aspects in order to deploy processes in run-time software environments. However, this focus on the control flow within business processes makes them less suitable for accessing the business space at the conceptual (i.e. implementation-independent) level. The ARIS tool and methodology [7] addressed this gap by combining a conceptual model of an enterprise with the actual production system. Semantic Business Process Management (SBPM) [3, 8] further extends this Business Process Management (BPM) view to increase the level of automation. Like in traditional BPM methodologies, the Semantic Business Process (SBP) life cycle has four phases: SBP modelling, SBP configuration, SBP execution and SBP analysis. When taking a closer

Page 87

SBPM 2008 Proceedings

look at SBP modelling, we discover that actors playing the role of business process modeller are the envisioned users of the SBPM modelling tools [9]. One of the main tasks of business process modellers is to create process models using the Business Process Modelling Ontology (BPMO - version 1.4), and annotate these models with ontological constructs. Unfortunately, SBPM does not provide explicit support to capture the requirements coming from the business process owner, which normally serve as input for the work of the business process modeller. We will refer to these requirements as ‘early’ requirements as they relate to the goals of the business process, the (alternative) means to achieve these goals (i.e. activities and resources) and constraints that apply (e.g. limited resources, time constraints), but generally do not include detailed requirements regarding manual/technological solutions. Our research suggests that explicit support to capture these early system requirements will improve communication between the process owner and the process modeller. We will propose a toolkit (Section 2), to be used by the process owner to facilitate requirements elicitation and structuring, and we formulate a semi-automatic translation (Section 3) from these early requirements into preliminary BPMO diagrams (Figure 1). It is our objective to reuse the entire SBPM ontology structure during this automatic translation, although in this paper we only focus on BPMO. Later on, the process modeller can further enrich the generated BPMO diagrams using available SBPM ontologies. process owner

early requirements

process modeller input

BPMO diagram

(toolkit)

Fig. 1: Empowering business process owners

2

A toolkit for the process owner

Research in the area of Management Science suggests that product design done by the product user is far more efficient than innovation by product manufacturers [10]. It is proposed to outsource need-related innovation tasks to the users themselves after equipping them with toolkits for user innovation. For example, a toolkit to create pizzas at home could consist of a box full of pizza dough with tomato sauce (generic solution), while several toppings plus a manual describing tasty topping combinations would be provided (adapting solution to user needs). Toolkits allow rapidly changing user needs (e.g. changing a mozzarella pizza into a pepperoni by adding salami) and help to elicit tacit user requirements by user iteration (e.g. discovering a rare but tasty combination of toppings). As an example in the business/IT field, Ricken & Steinhorst [11] propose to empower a business user by considering the Supply-Chain Operations Reference-model (SCOR) as a toolkit for business process innovation. In our research, we propose to use the first phases of the Tropos methodology [12] as a toolkit mechanism. The Tropos project provides a model-driven methodology where i* models [13] are used to drive the generation of software systems. The first two phases are acquisition of early requirements and defining late requirements, on which subsequent design and implementation are based. Our interest in Tropos is

Page 88

SBPM 2008 Proceedings

motivated by the large body of research done, and by the evidence of industry practices using Tropos as an information systems development method [14]. Although run-time environments such as TAOM4E [15] support the Tropos methodology, we limit the usage of Tropos concepts in this paper to the graphical notation. The i* modelling framework provides us with different modelling constructs to specify intentionality. A goal node in the goal tree shows that there are alternative ways of achieving the goal, but no specific instructions are given how to achieve the goal (e.g. when a car owner enters a repair shop and asks to “just get it fixed”). A task node shows that we specifically know what to do but there are constraints on how to do it (e.g. the car owner asks the repair shop to raise the engine idle settings in order to fix the engine). A resource node shows that getting the resource is unproblematic (e.g. getting new oil to fix the car), and a softgoal node will state the non-functional requirements to be attained while performing the task (e.g. have the car fixed economically). Using these constructs, the i* Strategic Dependency (SD) model describes a business process in terms of intentional dependency relationships among agents. The i* Strategic Rationale (SR) model describes the internal process in more detail from the point of view of one of the agents. In the SR model, task-decomposition links provide a hierarchical description of intentional elements and means-ends links provide the understanding about why an actor would engage in some tasks, pursue a goal, need a resource or want a softgoal. To give a practical example of how the toolkit can be used, we will describe the (simplified) use case ‘VOIP Order Fulfilment’ of Telekomunikacja Polska (TP) [16], related to the provisioning of the Voice-Over-IP (VOIP) telephony service. The TP business manager, responsible for this VOIP process, starts by plotting two actors (Customer and TP) and their mutual dependencies. The customer is dependent on TP to buy VOIP services, but is not expected to be interested in how this goal is fulfilled (“just give me VOIP”). Furthermore, the customer is expected to pay a certain amount of money to TP (Figure 2). Using task decomposition and means-ends links, the process owner expresses a high-level view on the current way of working: handling billing, handling orders and managing staff. Orders can be requested via telephone, in person or via an order page on the customer website (Figure 3). Suppose now that the process owner desires that the current order page on the corporate website, which has to be filled in manually, is replaced by an automated order system using Semantic BPMS technology. BuyVOIPService

TP

D

D

HandleOrders

Customer

D

RunTP

D

D

D

OrderBy Phone

HandleBilling TP

Customer

OrderVia Website

OrderIn Person

Payment BuyVOIPService

Manage Staff

D Payment

Fig. 3: SR model early requirements phase

D

Fig. 2: SD model early requirements phase

Page 89

SBPM 2008 Proceedings

The second phase of the Tropos project, definition of late requirements, reworks these models. First, an actor to represent the software system-to-be is included in the original SD model, and then a means-end analysis for this ‘system actor’ is initiated. As a consequence, the process owner adds the system as actor (VOIP Fulfilment System) to the original, early phase SD model. He assumes that customers would like to place orders in a secure environment, while TP wants the system to automate the existing manual processing of orders (Figure 4). The VOIP fulfilment system has to manage orders by taking customer order requests and fulfilling these orders. As known to the process manager, the CustomerOrderRequest goal is decomposed in three sub-tasks: CustomerIdentification, CustomerVerification and CaseCreation. To ensure the security standards, CustomerIdentification and CustomerVerification are expected to contribute positively to the overall system security (Figure 5). BuyVOIPService

D

D

TP

Customer

Security

D

D Customer

+ +

D

D

Payment

D

D D

PlaceOrder

D

CaseCreation

Customer Verification

Fig. 4: SD model late requirements phase

3

VOIP Fulfilment System

D

Security

VOIP Fulfilment System

CustomerOrder Request

Customer Identification

ProcessOrders Automatically

D

ProcessOrders Automatically

CustomerOrder Fulfilment

Secure TP

D

D D

Manage VOIPOrders

D

D

D

PlaceOrder

D

BuyVOIPService

D

Payment

Fig. 5: SR model late requirements phase

Mapping toolkit information to BPMO diagrams

When the process owner has structured his preliminary system requirements regarding the process, the information in the toolkit is ready to be transferred to the SBPM modelling environment. We will propose a mapping algorithm by means of the TP use case. A more formal version of the algorithm could be based on the formal specification of i*, Formal Tropos [17], and can be included in future research. The mapping algorithm starts by creating a BPMO diagram and by giving it the name of the highest i* task found in the systems’ actor SR model (ManageVOIPOrders). Followed by adding a Start and End event, we investigate the task decomposition links leaving the ManageVOIPOrders node. When encountering an i* Task leaf node, the algorithm inserts a Task element in the BPMO diagram. Nevertheless, the type of Task element is yet to be decided: when manual work is expressed by the i* leaf node, create a ManualTask; when existing web services can be used to implement this leaf node, create a WebServiceTask; when no existing web services are known at this point, create a GoalTask in the BPMO diagram and express desired functionality by means of Web Service Modeling Ontology (WSMO) Goals.

Page 90

SBPM 2008 Proceedings

Discovering the goal node CustomerOrderRequest, all task decomposition links leading to subtasks are investigated. The first task leaf node found is CustomerIdentification; thus, a GoalTask CustomerIdentification is added to the BPMO diagram (as no existing web services are known at this point). Using the same reasoning will add GoalTasks CustomerVerification and CaseCreation. The mapping algorithm will stop when discovering the goal CustomerOrderFulfilment as this goal has no children. Finally, the process modeller observes the semi-automatically generated BPMO diagrams in the SBPM modelling environment, and can add further implementation details such as control flow aspects or additional GoalTasks such as CustomerIdentifiedProblems (Figure 6).

Figure 6: The BPMO diagram resulting from Tropos models

4

Conclusion & Future Research

In order to empower the business process owner to structure his early phase system requirements regarding the process, we proposed a toolkit based on the first stages of the Tropos project. A mapping algorithm was described to translate the toolkit knowledge into BPMO diagrams, as defined by the SBPM modelling environment. Future research could explore how knowledge acquisition methodologies, other then the ones used in Tropos, can support early requirements elicitation. Furthermore, it would be possible to adapt an existing Tropos run-time environment (such as TAOM4E) to create a working demo for our toolkit. A formal version of the proposed mapping algorithm can also be designed based on the Formal Tropos language. Finally, the integration between the entire SBPM ontology structure and the toolkit can be intensified (e.g. Business Function Ontology).

Page 91

SBPM 2008 Proceedings

5 [1] [2] [3] [4] [5] [6] [7] [8]

[9] [10] [11] [12] [13] [14]

[15] [16] [17]

References N. Ahituv, M. Hadass, and S. Neumann, "A Flexible Approach to Information System Development," MIS Quarterly, vol. 8, pp. 69-78, Jun84 1984. J. Mylopoulos, "Information modeling in the time of the revolution," Information Systems, vol. 23, pp. 127-155, 1998. M. Hepp and D. Roman, "An ontology framework for semantic business process management," Proceedings of Wirtschaftsinformatik, Feb 28 - Mar 2 2007. M. Fox and M. Gruninger, "Enterprise Modeling," AI Magazine, vol. Fall 1998, pp. 109-121, 1998. J. Dietz, Enterprise Ontology: Theory and Methodology: Springer-Verlag New York, Inc., 2006. OASIS, "Web Services Business Process Execution Language Version 2.0," http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf, 2007. A.-W. Scheer, ARIS - Business Process Modeling: Springer-Verlag New York, Inc., 2000. M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel, "Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management," in Proceedings of the IEEE International Conference on e-Business Engineering: IEEE Computer Society, 2005. SUPER, "D5.1: Semantic Process Modelling Environment," in www.superip.org, 2007. E. v. Hippel and R. Katz, "Shifting Innovation to Users via Toolkits," Management Science, vol. 48, pp. 821-833, 2002. A. Ricken and A. Steinhorst, "Why working with reference models increases process innovation," BPTrends, vol. February, 2006. J. Castro, M. Kolp, and J. Mylopoulos, "Towards requirements-driven information systems engineering: the Tropos project," Information Systems, vol. 27, pp. 365-389, 2002. E. S.-K. Yu, "Modelling strategic relationships for process reengineering," University of Toronto, 1995, p. 181. H. Estrada, A. Rebollar, O. Pastor, and J. Mylopoulos, "An Empirical Evaluation of the i* Framework in a Model-Based Software Generation Environment," in Advanced Information Systems Engineering, 2006, pp. 513-527. A. Perini, A. Susi, L. Penserini, D. Bertolini, and A. Novikau, "TAOM4E," http://sra.itc.it/tools/taom4e/, 2008. SUPER, "D3.2: Dynamic Composition Reasoning Framework and Prototype," in www.super-ip.org, 2007. A. Fuxman, J. Mylopoulos, M. Pistore, and P. Traverso, "Model Checking Early Requirements Specifications in Tropos," in Proceedings of the Fifth IEEE International Symposium on Requirements Engineering (RE '01): IEEE Computer Society, 2001.

Page 92

SBPM 2008 Proceedings

Contextualized Ontology-Based Similarity in Human-Resource Domain: A Business Use Case Sinan Sen1 and Slavko Tomcic2 1

Research Center for Information Technology - FZI, Karlsruhe, Germany 2 living-e AG, Karlsruhe, Germany [email protected], [email protected]

Abstract. We are currently devoloping an integrated business application platform named Corinna3 where the long-term goal is to combine Semantic Web technologies with Natural Language Processing (NLP) to increase the efficiency of the enterprise search process. In this paper we consider one of the Corinna use cases, namely the Human Resource (HR) use case, which has already reached a prototype implementation. While NLP is used for automatic categorization of an unstructured resource, ontologies represent these resources in a taxonomical way with arbitrary properties. On top of the resource ontologies we use both the NLP for the information extraction as well as ontology-based similarity in order to get more acceptable similar search results. Our implemented approach of contextualized hybrid similarity search within the Corinna platform derives strongly from the defined business use cases. It combines and extends existing similarity measures under consideration of additional context information.

1

Introduction

Although enterprise resources are main factors of companies’ success it is still a challenging and time consuming task to search for these resources. HR is one of these resources and according to [1] companies’ greatest asset. One important issue in HR planning process is to find suitable job applicants fitting a certain job description. Based on the fact that the number of young professionals in Germany will decrease in the next decades [2] HR management will become important more than ever. Nevertheless the existing tools for HR management are developed proprietarly and the usage is still very time consuming. One main problem of these tools is that the HR professionals feel really overstrained with the personnel selection process. However without a reliable tool support it is a challenge to optimize the process. In this paper, we present a platform based on NLP and ontologies to improve the HR process especially the process of personnel selection. NLP is necessary since both the job description and the applicants data are mostly unstructured. Based on ontologies we show that ontology-based similarity is needed to leverage 3

Corinna is an acronym for CORporate INtelligeNce Applications

Page 93

2

SBPM 2008 Proceedings

Sinan Sen and Slavko Tomcic

the existing search process based on databases. The combination of different similarity measures is necessary in order to be independent from certain ontology structure. We also address the issue of context and show the importance of context for similarity search process.

2

Background

Ontology Existing HR applications are optimized for exact matches. In some cases if no exact match is available some relations between new instances and existing ones are added in order to get similar results, which is quite troublesome. We have chosen ontologies4 within the Corinna platform as the foundation of similarity search because they contain a controlled vocabulary given in the form of a hierarchical structure. We use an ontology as a collection of terms and definitions relevant to the business enterprise like presented in [3] and [4]. Similarity One approach to define a similarity measure is by using the notion of “ontology-based similarity”, which helps finding elements in the domain of interest that are conceptually close but not identical. While in the field of psychology it is important to identify how people classify objects and solve problems, computer scientists are focused on using similarity as an integral part of information processing such as information retrieval, natural language processing or information integration [5]. Ontology-based similarity can be further divided into two separate fragments, namely taxonomy-based similarity (see [6]) and featurebased similarity (see [7] and [8]). Context One major shortcoming of computer-based similarity judgement is that the results do not fulfill all users’ requirements [9]. This is mostly due to a lack of context information. Dey et al. [10] define context as any information that can be used to characterize the situation of an entity. For the similarity measurement, by context we mean additional information that narrows down the entity, in our case the search query for a certain skill, by influencing the similarity measure at run time. For example, searching for a job candidate with Java skills and web application skills as context information yields different results then searching for Java skills alone.

3

Corinna Business Platform

Corinna is a software platform for developing distributed and loose coupled application components. The goal of Corinna is to provide a lightweighted platform for the execution of the business processes. The components developed on Corinna basis can be reused easily and combined to obtain new system functions. The workflow engine is the core of Corinna platform (see figure 1). It obtains the executional infrastructure for the processes and activities. We designed Corinna to be the base for building the specialized ontology based and event driven system components. Those components are developed 4

As ontology representation language we use OWL

Page 94

SBPM 2008 Proceedings

Contextualized Ontology-base similarity in Human-Resource Domain

3

for certain tasks and grouped into system modules that are displayed in Figure 1 and briefly described below.

Fig. 1. System Overview

The module Information extraction is responsible for the structuring of an unstructured text content. In HR use case information extraction has been used both for gathering the information from submitted applicants documents and as well as for the extraction of the context information from the job description. The both scenarios are realized with the help of the existing NLP frameworks5. The information extracted from applicants documents will be submitted to the knowledge base and in second case, extracted information will be used to define the search request. The Semantic Platform is a set of specialized Corinna components. It obtains the mechanism for grouping and manipulating of ontology modules and provides the binding environment for specialized reasoners. Further it provides the connection to the different data stores, obtains the infrastructure for the data updates and implements N-Triple storage for submitted facts. Although the Semantic Platform provides mechanism for manipulation of ontology data, it is not optimized for the search. Therefore the Index and Search subsystem is designed to provide the optimal search performance. To reach optimal search performance we are using specialized index engine6 that enables fast indexing and search. 5 6

We use the NLP framework Mindset by Xtramind: http://xtramind.com/de/Produkte/mindset/Mindset.php As index engine we use Apache Lucene

Page 95

4

SBPM 2008 Proceedings

Sinan Sen and Slavko Tomcic

Here we are going to describe the search process which realizes the find applicant use case: Activity 1: receive search request and calculate similarities At the beginning of the search workflow the search profiles are analyzed and the similarity is calculated. For each skill defined in the search profile the n most similar skills would be found. The similar skills are delivered as result with the calculated similarity factor7 . Activity 2: create the search query based on the requested parameters and calculated similarities The modified search profile with calculated similar skills is passed to the next step where the search profile is translated into concrete search queries. The similarity factor is used here as boost factor in the query construction. Activity 3:execute the query and return the results Query has been executed and the list with search results will be returned back. Each entry from the list contains applicant profile and relevancy score. Relevancy score is related to the similarity factor used by query construction.

4

Contextualized Hybrid Similarity

As we described above one aim of Corinna should be to calculate the similarity between ontology instances. Thus the objective is to derive a function sim(I1 , I2 ) that measures the distance between the current skill instance I1 and the next skill instance I2 . We assume that the similarity function maps instances of an ontology O into the unit interval: sim(x, y) : I × I → [0, 1] where I is the ontology instance which represents the skill instances. Different similarity measures can be considered in die aggregation function simA .  simA (I1 , I2 ) := ni=1 ωi ∗simni (I1 ,I2 ) At the moment two different types of similarity measures are used, namely similarity based on the ontology taxonomy simtx and similarity based on the ontology properties simpr . The importance of each measure can be controlled via the parameter ω. In order to calculate simtx it is necessary to look into the taxonomy and identify which concepts connect I1 and I2 . In a simple way this can be considered as the shortest path between the two skill instances. In this paper we use the semantic cotopy presented in [11] as an taxonomy based similarity measure. Within the similarity calculation contextual information can influence the ranking list of the most similar skill instances. In our approach the contextual information are considered in the feature-based similarity simpr . 7

similarity factor is a value between 0 and 1 generated by the similarity component

Page 96

SBPM 2008 Proceedings

Contextualized Ontology-base similarity in Human-Resource Domain

simpr (I1 , I2 ) :=

α∗vrcc +β∗vrc ωf ∗ α∗vrcc +β∗v +γ∗v rc +δ∗v r−c

5

c−r

k

The function fdist calculates the similarity for every equivalent property in I1 and I2 under consideration of existing context information. vrcc expresses how many values I1 and I2 have in common with respect to the context for each property vrc expresses how many values I1 and II2 have in common for each property vr−c expresses how many values are I1 and not in I2 for each property vc−r expresses how many values are I1 and not in I2 for each property The result of the calculation is normalized by the value k whereby k represents the number of distinct properties in both skill instances. Like the weight-value used by the aggregation function we define a weight ωf which expresses the importance of a property. The parts of fdist which increase or decrease the similarity also have weights.

5

Related Work

Hefke et. al. [12] calculates the similarity of two entities called complex entities following the local-global- principle. The assumption behind this is that two complex objects are built up from smaller units. Although they combine taxonomic similarity, set similarity and relational similarity they do not consider the importance of the similarity context. The work done by Biesalski and Abecker [13] uses the similarity for skill profiles within a project staffing module. The idea is the ontology-based modelling of employees’ skill profiles. To support the project staffing they match position skill requirements with employee’s skill profile. Mochol et. al. [14] uses some semantic web technologies to match job postings and applications. They cluster the information about competencies and skills and calculate the similarity of these thematic clusters. However this approach is also restricted to the recruitment domain and does not consider the dependency of similarity with additional context information.

6

Conclusion

Our goal in this paper was to present one of the main use cases, namely the HR use case, within the Corinna platform. The objective of Corinna is to combine NLP with semantic web technologies in order to leverage the process of enterprise search. We described the ontology-based similarity as a factor to improve the personnel search process. Since the similarity is dynamic and depends on context we introduced the importance of additional background information. Within the Corinna platform we developed a similarity module which is based on different similarity measures, namely taxonomy-based and feature-based, using context information. Since we have only an informal feedback at the moment we will

Page 97

6

SBPM 2008 Proceedings

Sinan Sen and Slavko Tomcic

carry out an expert evaluation. Also a system performance and a scalability test are planned for the near future. Furthermore we want to implement additional similarity measures with respect to the contextual information.

References 1. Harris, J., Brannick, J. In: Finding and Keeping Great Employees. Amacom (1999) 2. Germany, F.S.O.: Bev¨ olkerung deutschlands bis 2050 ergebnisse der 10. koordinierten bevlkerungsvorausberechnung. Pressestelle Wiesbaden (2003) Statistisches Bundesamt, Wiesbaden 2003. In German. 3. Fox, M., Chionglo, J., Fadel, F.: A common sense model of the enterprise: In proceedings of the 2nd industrial engineering research conference, volume 1, pages 425–429, norcross ga, usa, 1993. 4. Uschold, M., King, M., Moralee, S., Zorgios, Y.: The enterprise ontology (1995) 5. Rodr´ıguez, M.A., Egenhofer, M.J.: Comparing geospatial entity classes: An asymmetric and context-dependent similarity measure 6. Pedersen, T., Pakhomov, S.V.S., Patwardhan, S., Chute, C.G.: Measures of semantic similarity and relatedness in the biomedical domain. J. of Biomedical Informatics 40(3) (2007) 288–299 7. Hirakawa, H., Xu, Z., Haase, K.: Inherited feature-based similarity measure based on large semantic hierarchy and large text corpus (1996) 8. Tversky, A.: Features of similarity (1977) 9. Janowicz, K.: Kinds of contexts and their impact on semantic similarity measurement. In: 5th IEEE Workshop on Context Modeling and Reasoning (CoMoRea) at the 6th IEEE International Conference on Pervasive Computing and Communication (PerCom08). (2008) 10. Abowd, G.D., Dey, A.K., Brown, P.J., Davies, N., Smith, M., Steggles, P.: Towards a better understanding of context and context-awareness. In: HUC ’99: Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing, London, UK, Springer-Verlag (1999) 304–307 11. Maedche, A., Staab, S., Stojanovic, N., Studer, R., Sure, Y.: Semantic portal - the seal approach (2001) 12. Hefke, M., Zacharias, V., Abecker, A., Wang, Q., Biesalski, E., Breiter, M.: An extendable java framework for instance similarities in ontologies. In: ICEIS (2). (2006) 263–269 13. Biesalski, E., Abecker, A.: Similarity measures for skill-profile matching in enterprise knowledge management. In: ICEIS (2). (2006) 11–16 14. Mochol, M., Oldakowski, R., Heese, R.: Ontology based recruitment process

Page 98

SBPM 2008 Proceedings

Towards a Simulation-based Communication Tool to Support Semantic Business Process Management Paul Stynes1, Owen Conlan2 and Declan O’Sullivan2 1

National College of Ireland, Dublin, Ireland [email protected]

2

School of Computer Science and Statistics, Trinity College, Dublin, Ireland {Owen.Conlan, Declan.OSullivan}@cs.tcd.ie

Abstract. Successfully communicating a Business Executive’s goals and desires to an IT Architect with regard to organizational change presents a major challenge. The most significant problem is relating the changes desired in a semantically consistent and understandable manner and then reflecting the potential impact of those changes on the organizational structure and the business processes carried out within that organization. This paper presents a proposal for a simulation-based communication tool that employs a semantically driven natural-language component to capture a Business Executive’s needs. These needs are translated into a simulation of a business process consisting of semantic web services that represent the evolution of the organizations IT infrastructure and policies. Through an iterative communication loop with the IT Architect the simulation can be used to accurately represent the changes necessary to meet the Business Executive’s needs. Keywords: Communication, Simulation, Natural Language, SBPM

Introduction Effective communication between Business Executives and IT personnel is essential to ensure the IT architecture evolves to support an organisations business needs. Business Executives naturally view the organisation from a business point of view that encompasses the business needs to meet customer requirements in an effective and efficient manner. Communicating these needs often presents a problem as the vocabulary used by a Business Executive does not always correspond to that used by the IT Architect. Indeed, business needs and goals are typically expressed in natural language, which are subsequently used as the basis of functional specifications expressed in a modelling language such as the Unified Modelling Language (UML). Natural language is ambiguous and open to misinterpretation, but UML and its peers are often inscrutable and provide difficulties in envisioning how the solution will be realised. This communication mismatch poses a severe and potentially very costly challenge between the Business Executive and IT Architect that often leads to delays and misunderstandings in defining the IT architecture.

Page 99

SBPM 2008 Proceedings

Semantic Business Process Management (SBPM) [7] has the potential to provide a fundamental basis for a common semantic understanding between the Business Executive and the IT Architect. As an approach it espouses the inclusion of ‘meaning’ in business processes. However, the problem of how this meaning will be communicated and negotiated still exists. The authors accept that changes to the organisation and IT required by organisational strategy and vision are not simple and require iterative communication between the Executive and IT Architect. This paper proposes simulation as a basis for communication, is a mechanism for achieving this. The approach utilises a semantically-driven natural language processing to refine a Business Executive’s goals in terms compatible with SBPM and then reflect the potential changes to the IT architecture using web service based simulations. Thus, simulation provides the Executive and IT Architect, with the ability to collaborate interactively in a user-centric and semantically consistent way in order to improve the effectiveness and efficiency of communication and reduce misunderstandings. The structure of this paper is as follows, firstly an introduction to related work to ground this research in the theory between Semantic Business Process Management (SBPM), Semantically Controlled Natural Language Interfaces (SCNLI) and Simulation. The second section outlines the technical approach and functionality. The third section describes a scenario-based evaluation of the first prototype. The final section discusses this research and expected future direction.

Related Work This research relates to the intersection between Semantic Business Process Management (SBPM), Semantically Controlled Natural Language Interfaces (SCNLI), and Simulation. Business Process Management (BPM) is an approach to manage the execution of IT-supported business operations from a business expert’s point of view rather than from a purely technical perspective. Hepp et al. [7] recognize that the degree of mechanization in BPM is limited and they trace the problem of mechanization of BPM to an ontological one, i.e. the lack of machine accessible semantics. They argue that the modeling constructs of Semantic Web Services (SWS) frameworks are a natural fit and propose to combine SWS and BPM to create one consolidated approach, Semantic Business Process Management (SBPM). In [8], Hepp et al outline the representational requirements of SBPM, propose a set of ontologies and formalisms and define the scope of the ontologies through competency questions. The spheres that are represented in an SPBM framework relate to Processes, Process Models, Organization, Corporate Strategy, Constraints, Business Functions, and Transactional and Customizing Data. They describe competency questions that allow them to describe the ontologies and formalisms for the spheres. There also exists other enterprise ontologies which could be used for SBPM such as [4][5][6]. Wetztein et al. [9] builds on Hepp’s vision and describes the incorporation of ontologies and semantic web service technologies into the BPM lifecycle. The lifecycle consists of process modelling, implementation, execution, and analysis phases.

Page 100

SBPM 2008 Proceedings

Bernstein et al. [1][2] introduce a Guided Input Natural Language Ontology editor (GINO) that can edit and query ontologies. GINO allows users to enter a guided input sentence through natural language, which is then translated into triple sets or SPARQL statements. Wang et al. [11] presents a portable natural language interface to ontologies (PANTO) that accepts generic natural language queries and outputs SPARQL queries. Schwitter [10] shows how a controlled natural language describes knowledge for the semantic web. These approaches show the potential for natural language interfaces to utilize semantic inference to refine and hone the user’s goals. Simulation plays an important and inexpensive role in answering what-if questions during process composition. Web based simulation offers an approach to dynamically model a system and make changes to optimise resources in a consequence free environment. The true potential of simulation is in portraying the envisaged impact of certain decisions and changes on an operational system or process. Chandrasekaran et al in [3] examines the synergy between web service technology and simulation. One of the approaches they propose is the creation of simulation models/components from web services in order to provide a high fidelity between the simulation and real world. It provides an ability to plug real web services into simulated entities, thus creating simulations that utilise as much ‘real world’ data as possible.

Proposed Approach The approach proposed in this paper focuses on a user-centric approach to a lightweight collaborative interaction between the Business Executive and the IT Architect. The Simulation-based Communication Tool allows the Business Executive specify their goals and rules for organisational change through a semantically controlled natural language interface. The system interprets the goal and identifies the business process that can deliver the appropriate services. Then it adapts the services using rules specified with the goal. Through simulation, the Executive may review the impact their goal and rules have on the services of the organisation. This semantically driven approach ensures the terminology used in the specification of goals is consistent with the capabilities of the IT architecture. These goals will be realised by the orchestration of both existing and simulated web services that represents the new/modified business processes. The architecture of the Simulation-based Communication Tool (SCT) is shown in Figure 1 and will be applied to an organisation represented by an institute of higher education. To-date part of the ontology that models the institutes of higher education is modelled based on OWL and stored in Jena. As part of a prototype due in September 2008, the Semantic Analysis (SA) component will interpret the goal and identify the business process that delivers the appropriate services by using SWRL rules that use the domain ontology. The SA component uses the rules specified with the goal to adapt the services of the business process. The simulation platform is the execution environment that produces the simulation. The technologies it uses are Business Process Execution Language (BPEL) to describe the executable business process and the orchestration of services that

Page 101

SBPM 2008 Proceedings

comprise the process. The services represent real or simulated web services of organisational roles and constraints on those roles, current and future IT systems. Currently a BPEL process that orchestrates the interaction between simulated web services has been created. The simulated web services represent the Programmes, Faculty and Classroom resources in institutes of higher education. It is envisaged that the web services will be semantically enabled to ensure that they are automatically identifiable using the Web Service Modelling Ontology. Through simulation, the Executive may review the impact their goal and rules have on the resources and IT systems of the organisation. The Outcomes component displays successful changes to the organization and business rules that violate organisational constraints. Through several iterations, the Executive may modify, add, or delete rules until they are satisfied with the potential changes to the organisation as witnessed through the simulated outputs. The resulting web service orchestration that fulfils the Executives goal and rules represents the technology platform that supports agile process change as shown in the Technology Platform component. Prototype

Simulation Platform

Technology Platform Semantically Controlled Natural Language Interface Business Executive

Semantic Analysis

Technologies

IT Architect Outcomes BPEL WSMO Web services

Domain Data Model

Figure 1 Architecture of a Simulation based Communication Tool

Prototype experiment An initial scenario-based evaluation consisting of a PowerPoint mock-up of a natural language user interface for the Business Executive was created around the specific scenario of planning changes to Faculty, Programmes and Classrooms within a higher education setting. The prototype simulates a user interface through a preplanned sequence of actions and mouse clicks as shown in Figure 2. The Executive can enter a goal and rules such as “Schedule the BSc (Hons) in Software Systems where Faculty teach 14 hours per week”. Ten participants that took part in this study were executives involved in the process of scheduling academics to programmes and classrooms. The executives comprise of the following roles, one vice president, five heads of schools, two heads of

Page 102

SBPM 2008 Proceedings

department, one acting head of school and one ex-head of school. The study measured the desirability of executives for a semantically grounded controlled natural language interface through the administration of a questionnaire containing 30 items. The major content sections of the questionnaire are Demographics; Perceived Usefulness; Usability Heuristics; User Interface Satisfaction; Screen; Learning; and Project Specific questions; The majority of items are based on a 5 point semantic differential scale. Other items gather feedback on the executive’s perceptions of the positive and negative aspects of the system including any suggested improvements to the system and other scenarios that are relevant to their job. Schedule Workflow consists of rules for resources related to Programmes, Faculty and Rooms Specify Organizational Rules and Constraints

Drag and drop resources to the Goal Editor

Figure 2 Simulation-based Communication User Interface The analysed data produce results, which indicate that the majority (60%) of this small group of executives desire a semantically controlled natural language interface for specifying goals and rules. A system that automatically interprets a goal to identify a business process, and applies rules to services in the process, is desirable among 70% of Executives. In addition, 60% of Executives welcome a visualisation that displays successful changes to the organization, as well as business rules that violate business constraints. Some of the comments made by executives that indicate this approach as being desirable are “The idea seems to be very good, esp. the natural language interface, which I particularly like”; “Use of English to set goals”; “Good HCI”; “System will interpret the goal and identify the org process for appropriate service”;

Discussion and Future Work This research introduces a Simulation-based Communication Tool (SCT), which offers a user-centric approach to lightweight collaborative interaction between the Business Executive and the IT architect. The purpose of which is to define the evolution of the IT architecture to support the Business Executive’s needs through a series of simulations. Results from an initial prototype evaluation indicate that the majority of a small group of executives like the approach of specifying their goals and rules in natural language. In addition, the majority of Executives liked the approach where the system automatically identifies a business process that may solve the

Page 103

SBPM 2008 Proceedings

Executive’s goal, and applies rules to services in the process. Executives also welcome a visualisation that displays successful changes to the organization, as well as business rules that violate business constraints. Future work will involve the evolving of SCT as part of doctorial research. This involves an investigation of controlled natural language interfaces, completing the domain ontology for higher education, mapping goals and rules to a workflow language such as BPEL, and modifying the web-services so that they are semantically enabled. It is envisaged that a prototype will be ready by September 2008.

References [1]

[2]

[3]

[4] [5] [6]

[7]

[8]

[9]

[10]

[11]

Bernstein, A. & Kaufmann, E. (2006) GINO-A Guided Input Natural Language Ontology Editor. IN: Proceedings of the 5th International Semantic Web Conference.(ISWC 2006), 5-9, November, Athens, USA. Berlin, Springer..pp. 144-157. Bernstein, A., Kaufmann, E., Göhring, A. & Kiefer, C. (2005) Querying Ontologies: A Controlled English Interface for End-Users. IN: Proceedings of the 4th International Semantic Web Conference (ISWC 2005), 6-10 November, Galway, Ireland. Berlin, Springer. pp 112-126. Chandrasekaran, S., Silver, G., Miller, J., Cardoso, J. & Sheth, A. (2002) XML-based modeling and simulation: Web service technologies and their synergy with simulation. IN: Proceedings of the 34th Winter Simulation Conference: exploring new frontiers (WSC 2002), 8-11, December, San Diego, California, USA. Winter Simulation Conference. pp 606-615. Dietz, Jan L.G. Enterprise Ontology. Springer, Berlin/Heidelberg 2006. Fox, M. S., Barbuceanu, M., Gruninger, M., Lin, J. (1998) An organization ontology for enterprise modeling IN AI Magazine, Fall 1998, pp. 102-121. Fox, M.S., (1992), "The TOVE Project: A Common-sense Model of the Enterprise", Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, Belli, F. and Radermacher, F.J. (Eds.), Lecture Notes in Artificial Intelligence # 604, Berlin: SpringerVerlag, pp. 25-34. Hepp, M., Leymann, F., Domingue, J., Wahler, A. & Fensel, D. (2005). Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. IEEE International Conference on e-Business Engineering (ICEBE 2005), 18th 21st October, Beijing, China. IEEE Computer Society, ISBN 0-7695-2430-3. pp. 535-540. Hepp, M., Roman, D. M. Hepp, D. Roman: An Ontology Framework for Semantic Business Process Management, proceedings of the 8th international conference Wirtschaftsinformatik 2007, February 28 - March 2, 2007, Karlsruhe. In: Oberweis, A; Weinhardt, C.; Gimpel, H.; Koschmider, A.; Pankratius, V.; Schmizler, B.: eOrganisation: Service-, Prozess, MarketEngineering, Vol. 1, Universitaetsverlag Karlsruhe, pp. 423-440. PDF available at http://www.heppnetz.de/files/hepp-roman-an-ontology-framework-for-SBPM-WI2007.pdf Wetzstein, B., Ma, Z., Filipowska, A., Kaczmarek, M., Bhiri, S., Losada, S., Lopez-Cobo, JM. & Cicurel, L. (2007) Semantic business process management: a lifecycle based requirements analysis. IN: Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM 2007), June 7th, Innsbruck, Austria. pp. 1-11. Available from: http://sbpm2007.fzi.de/ [Accessed on 29th February 2008]. Schwitter. R. (2005). A controlled natural language layer for the semantic web. IN: Proceedings of the 25th SGAI International Conference on Innovative Techniques and Applications of Artificial Intelligence (AI 2005), 12-14 December 2005, Cambridge, UK.Springer, Berlin. pp. 425-434. Wang, C., Xiong, M., Zhou, Q. & Yu. Y. (2007) Panto: a portable natural language interface to ontologies. IN: Proceedings of the 4th European Semantic Web Conference (ESWC 2007), 3-7 June, Innsbruck, Austria. Berlin, Springer-Verlagg. pp. 473-487.

Page 104

SBPM 2008 Proceedings

The Business Process as an Integration Platform: Case Studies from the EU-Projects LD-CAST and BREIN Dimitris Karagiannis1, Robert Woitsch2, Wilfrid Utz2, Hannes Eichner2, Vedran Hrgovcic2 1

University of Vienna, Department of Business and Knowledge Engineering, Brünnerstaße 72, 1210 Vienna, Austria [email protected] 2

BOC Asset Management GmbH, Bäckerstraße 5, 1010 Vienna, Austria {Robert.Woitsch, Wilfrid.Utz, Hannes.Eichner, Vedran.Hrgovcic}@boc-eu.com

Abstract. The integration of the business and technical views allows domain experts from the business view to take control over the whole process of service design and delivery. The integration approach of business and technical views presented in this paper is supported by semantic concepts integrating steps for ontology development, maintenance and evolution based upon available highlevel business process definitions defined and available at end-users’ scenarios. This approach is evaluated and presented through the use case example from the LD-CAST Project (FP6-ICT-26919) as well as BREIN (IST-FP6-034556). Keywords: Business process, Interoperability, Integration, Semantics

1 Introduction This paper focuses on the integration of semantic technologies with business process management and presents case studies from two related projects LD-CAST and BREIN which are co-funded by the EC under the Sixth Framework Programme. The main goal of LD-CAST (FP6-ICT-26919) [1] is the creation of a knowledge based system for the Chambers of Commerce in Bulgaria, Poland and Rumania that allows the usage of services in transparent, flexible and efficient way. This system should improve the support of SME initiatives in the Eastern European market. The BREIN project (IST-FP6-034556) [2] aims to realise flexible, intelligent virtual organisations support, to significantly reduce the complexity of modern day business-to-business collaborations. BREIN will create an infrastructure that will increase the level and dynamism of collaborations among companies, with special focus on SMEs. From a technical perspective technologies like grid, semantic web and multi-agents concepts are used for this intelligent and adaptable infrastructure. The paper presents an experience report (1) in the domain of eGovernment (LDCAST) and (2) in the context of an intelligent business grid (BREIN). In the eGovernment case the business processes were mainly used for the communication

Page 105

SBPM 2008 Proceedings

with business experts, deriving the system requirements and mapping the business processes to workflows. In BREIN business process modelling served as requirements elicitation process for the system architecture and as basis for ontology generation. The paper at hand is structured as follows: Chapter 2 discusses the details of the LD-CAST project. Chapter 3 deals with the BREIN project and presents the BREIN Modelling Framework. The conclusion and an outlook are provided in chapter 4.

2 LD-CAST – The Business Process as an Integration Platform The goal of LD-CAST is to foster cross-border cooperation between chambers of commerce and their clients. The business processes of the chambers are virtualised in the internet in order to allow the execution as workflows. The challenge is that these workflows need to provide sufficient flexibility in order to compose the workflow according to pre-defined parameters. The problem so far is that the delivery of business services pertaining to multiple countries has various problems related to the non-homogeneity of national terminology and processes. The LD-CAST system overcomes such problems, by introducing a modelling platform that drives the execution of business services [3]. The system uses ontologies for the coupling between business processes and workflows. The details are explained in this chapter. 2.1 The Business Process as an Integration Platform for Service Delivery In public administration process management has been largely used for improvement, modernisation, higher efficiency and for cost reduction summed up under New Public Management. In LD-CAST the business processes are taken as a basis for software development, configuration and the development of the knowledge based system. The starting point was the modelling of the chambers’ business processes. This was done using the modelling method ADOeGov® [4] which is based on a top-down approach: In a first step the services offered by the chambers were identified. It could be already seen that the offered services differed in type and in extent between the chambers in different countries. The next step concerned the refinement of the services through the representation of them as process-chains. Again a huge difference between the chambers could be noticed. In a third step the process description was completed by task descriptions, used resources, IT-systems and roles. Based on this detailed description the system requirements could be specified. Here activities were mapped to business use-cases, which then could be transformed into technical use cases. The business processes were not only basis for the system requirements, but were also used to derive the executable workflows (BPEL [5]). 2.2 LD-CAST Case-Study Overview and Project Methodology In order to allow domain experts to have control over the whole process of the service delivery to the end users - these two not easily compatible views had to be integrated into a functional system. Fig. 1 gives a brief overview of the relation of the two views,

2

Page 106

SBPM 2008 Proceedings

namely business episodes are fully integrated in the business view, while executable workflows are positioned in the technical view. Abstract workflows and ontology interconnect these two views. An additional aspect is the further separation of the business and technical views in the build time and run time layers [6]. To provide the required flexibility, LD-CAST distinguishes between three types of processes: Business episodes describing the services offered by the chambers, abstract workflows that are available in the build time environment and executable workflows where each step from the abstract workflow is bound to a concrete service.

Business View

Build Time

Run Time

Business Episodes Run Time Portal

no Akogrimo Emergency Scenario

Register as User

Record ECG

Transmit ECG

Should the ECG Data be continously recorded?

Analyze ECG

Initiate Emergency Call

yes Wait the configured time

Meta Model .

Technical View

Abstract Workflows

Workflows

Ontology Concrete Services

Fig. 1. Business and Technical View [6]

OPAL was used to link the abstract workflows with the concrete services, as it allows process related definition of ontologies [7]. The workflow activities and the concrete services were then annotated with OPAL concepts. For the execution of the workflows a concrete service for each action defined in the BPEL-process has to be discovered. Again the business processes were helpful for the creation of the OPAL ontology as the basic concepts, relations and structures could be recognized in the models. The models were regarded as basis content for the ontology which then has been completed with additional concepts. An alternative approach to reach flexibility of business processes is taken by the FIT project [8], which uses business process models and business rule models to realize an adaptive eGovernment system.

3 BREIN – An Integrated Modelling Framework The aim of BREIN is transferring business collaborations onto the Grid. This means taking the existing business and its services, but changing the underlying technology by transferring it to the Grid. In order to succeed in doing this, it is necessary to analyse the concrete business processes of the scenarios and to analyse the added value of the Grid. The BREIN Modelling Framework [9] allows performing these tasks. It has been defined to enable the process-oriented requirements analysis of

3 Page 107

SBPM 2008 Proceedings

applications, the specification of the software architecture and the externalisation of expert know-how. 3.1 The BREIN Modelling Framework

Business Models Supply ChainModelling

Business ProcessModelling

Modelling methods to be considered: SCOR ®

Modelling methods to be considered: BPMN, E-BPMS, EPC, IDEF, LOVEM-E

Horizontal integration

GoalModelling Modelling methods to be considered: GORE

IT Modelling Level

Vertical integration

Vertical integration

Workflows Workflows and and Service Service Description Description Modelling methods to be considered: BPEL, SAWSDL, OWL-WS, WS-CDL, WS-Agreement, WSLA, WS-Agreement Negotiation

Horizontal integration

Software Software Architecture Architecture

Best-Practice Roadmap Roadmap Best-Practice

Business Modelling Level

The BREIN Modelling Framework is based on the concepts of ATHENA [10], EMI [11] (Enterprise Model Integration), MDA [12] (Model Driven Architecture) and SOA [13] (Service Oriented Architectures). Consequently the Modelling Framework distinguishes between two levels of abstraction, (1) the Business Modelling Level and (2) the IT Modelling Level. Parallel to these two levels, a “Best Practise Roadmap” deals with knowledge management, allowing the knowledge transfer to new or external developers (see Fig. 2). Based on the requirement of the BREIN scenarios the business modelling layer has been instantiated with supply chains to model the inter-organisational perspective (e. g. SCOR), business processes to represent the intra-organisational view (e.g. BPMN [14], E-BPMS [15], EPC) and goal models to steer the business collaborations.

Modelling methods to be considered: UML 2.0

Fig. 2. The BREIN Modelling Framework

The IT Modelling Level is split into two building blocks. The first refers to Workflow and Service Description for the discovery and the execution of services and workflows (considering standards like BPEL [5] and OWL-WS [16]). The second building block concerns the Software Architecture to document the platform and for the technical specification of services (UML). 3.2 Business Processes in the Ontology Building Business process modelling has been widely used for process re-engineering purposes. In BREIN the notion of business process modelling goes one step further and takes business process modelling as a basis for software development. Apart from

4

Page 108

SBPM 2008 Proceedings

the process oriented requirements analysis the process models were taken as input for the generation of ontologies. Ontologies in BREIN are needed by software agents to carry out tasks such as service and resource discovery as well as resource scheduling and to enhance the interoperability. The problem is that these ontologies are rather technology-driven and do not contain business concepts. The Modelling Framework realizes an integration of meta-models and ontologies using a bootstrapping approach [9], [17], where these business process models may serve as basis for the creation of ontologies and vice versa. This is done by establishing a mapping between business process concepts and ontology concepts in form of a rule file. Based on this mapping the models can be transformed into ontologies automatically. Basically there are two ontologies that can be derived. First, an ontology on a meta-model layer, which is a list of business process modelling concepts. Second, an ontology on a model layer, which is a list representing the scenario concepts. Ontology feedback

Modelling process using card sorting

Top-down by domain experts

Ontology input

Ontology Domain input Modelling process using BPM4SOA

Bottom-up by knowledge engineers

Domain feedback

Fig. 3. Ontology generation approach

In parallel to this top-down approach, a bottom-up approach by knowledge engineers captured low level concepts which were integrated into the ontology. The combination of these approaches led to the definition of the ontologies in an iterative way where the top-down and the bottom-up approach continuously provided input but also received feedback from the ontology (see Fig. 3).

4 Conclusion Business processes have been successfully used as integration platform in the two projects. In the case of LD-CAST they build a communication platform and allowed the efficient involvement of business experts into the technical IT-layer. The approach taken lowers the complexity and allows business experts to take control over the service delivery process.

5 Page 109

SBPM 2008 Proceedings

In BREIN the business modelling framework allowed the process oriented requirements analysis and therefore the reflection of business concepts in the architecture. The created models allowed then the combination of top-down and bottom-up ontology building approaches. The integration of business aspects is a clear enrichment of the rather system-oriented ontologies. The presented framework is already in use as a prototype and will be further developed focusing on a better mapping between business and IT layer. Acknowledgements. We would like to thank our partners in the LD-CAST and the BREIN consortium, which provided valuable know-how from their domain of expertise this paper is based upon.

References 1. LD-CAST project, http://www.ldcastproject.com 2. BREIN project, http://www.gridsforbusiness.eu 3. Catapano, A., D'Atri, A., Hrgovcic, V., Ionita. D., Tarabanis, K.: LD-CAST: Local Development Cooperation Actions enabled by Semantic Technology, Eastern Europe e|Gov Days 2008, Prague, Czech Republic (2008) 4. Palkovits, S., Wimmer, M.: Processes in e-Government – A Holistic Framework for Modelling Electronic Public Services. In EGOV 2003, Springer Verlag, (2003) 5. IBM: BPEL, http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ 6. Karagiannis, D., Woitsch, R., Utz, W., Hrgovcic, V., Eichner, H.: Business Episodes and Workflow Integration: A Use Case in LD-CAST, ICIW (2008) 7. D’Antonio, F., Missikoff, M., Taglino, F.: Formalizing the OPAL eBusiness ontology design patterns with OWL. Third International Conference on Interoperability for Enterprise Applications and Software, I-ESA (2007) 8. Leutgeb, A., Utz, W., Woitsch, R., and Fill, H.-G.: Adaptive Processes in e-Government - A Field Report about Semantic-Based Approaches from the EU-Project "FIT", In: Proceedings of the International Conference on Enterprise Information Systems (ICEIS 07) (2007) 9. Woitsch, R. Eichner H., Hrgovcic V.: Modelling Interoperability: The Modelling Framework of BREIN, In: Interoperability for Enterprises: Software and Applications (IESA’08) Workshop Proceedings (2008) 10.ATHENA Project, http://www.athena-ip.org/ 11.Kühn, H., Bayer, F., Junginger, S., Karagiannis, D.: Enterprise Model Integration, Proceedings of the 4th International Conference ECWeb (2003) 12.Object Management Group: MDA Guide Version 1.0.1, http://www.omg.org/mda 13.OASIS: OASIS SOA Reference Model, http://www.oasis-open.org/ 14.OMG: BPMN 1.0, http://www.bpmn.org/ 15.Bayer, F., Junginger, S., Kühn, H.: A Business Process-oriented Methodology for Developing E-Business Applications. In: Proceedings of the 7th European Concurrent Engineering Converence (ECEC 2000), Society for Computer Simulation (SCS) (2000) 16.Beco, S., Cantalupo, B., Giammarino, L., Matskanis, N.: OWL-WS: a workflow ontology for dynamic grid service composition, e-Science and Grid Computing (2005) 17.Karkaletsis, V., Paliouras, G., Spyropoulos, C.: A Bootstrapping Approach to Knowledge Acquisition from Multimedia Content with Ontology Evolution, Adaptive Knowledge Representation & Reasoning (AKRR’05), Helsinki, Finland (2005)

6

Page 110