Design Evaluation – The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods (section 8);

A DEMO-based Service Mining approach

67061 Pedro Luís Linares Pinto

Orientador: Professor Miguel Mira da Silva Co-Orientador: Professor Artur Caetano

Abstract.

Presently services account for the biggest part of the world’s economy. Nevertheless, organizations do not carry on real time organizational models that portray their business processes and services, which can lead to uninformed decisions. Services are complex mainly because an initial service execution can lead to other cross-departmental and cross-organizational service executions. However, all the transactions involved between the several actor roles share the same essential pattern described in the Enterprise Ontology theory. In this thesis we propose to use Design & Engineering Methodology for Organizations (DEMO) to discover the chain of service executions that take place in the field within the execution of the organizational business processes. In our research we use the Design Science Research Methodology and we plan to develop a web-based system that will be evaluated through interviews with Service Management experts and field studies in real organizations.

Keywords: Services, Business Processes, Enterprise Ontology, DEMO, Service Mining, Process Mining

1. Introduction

Process orientation have proved to be an effective way of increasing organization performance by focusing on business processes instead of emphasizing organization’s functional and hierarchical structures [1]. Process orientation improves financial performance and delivery speed owing to the fact that by discovering and analyzing organization’s business processes it is easy to detect non-value activities which can be eliminated leading to cost reductions and time savings. Once that, in process orientation, business processes are aligned with customer requirements one can also expect that process orientation leads to higher customer satisfaction. Process performance measurement also relates positively with product quality. Besides, an organizational structure in line with organization’s business processes makes organizations faster at launching new products to the market [2].

process models, using information about the actual process recorded in some event log) [3].

However, there were evidences that the most efficiency gains can often only be achieved within the collaboration of different organizations [4] and by focusing only on a single process instance that implements a service one can be tempted to forget that two services can limit each other’s behavior as described in [5]. Besides, it has also been observed that within a single organization the departmental segmentations without an interdepartmental communication can have detrimental effects on the business processes [6]. Transforming isolated efforts into cross-functional activities also suggests the generation of business value [7].

The previous evidences suggest that it is useful to look at process instances as being correlated with other process instances from potentially different services [8]. The problem we want to tackle in this research is the absence of updated organizational models that are able to portray services and business processes. We do not want organizational leaders to make uninformed decisions based on assumed organizational models that does not match with the real ones.

Our proposal intends to solve the absence of updated organizational models that are able to portray real time business processes and services. For that purpose we use DEMO (section 5.2) so we can get organizational models that have within them the Enterprise Ontology-based Service definition described in section 3.1. We use this definition because it is powerful enough to describe services executed by both humans and machines. The objectives of our solution, which can be matched with the “Define objectives of a Solution” step in the Design Science and Research Methodology, are:

1. To discover real time Enterprise Ontology-based services;

2. To discover real time processes that do happen when we compose services performed by several actor roles;

We chose DEMO-based models mainly because their simplicity can help us to achieve a representation of the organization’s daily service executions without getting into implementation details, which is good for starting organizational analysis and reengineering. By representing service executions through the essence of those services, we believe that our system is a valuable tool for supporting the task of engineering and reengineering organizational processes.

The evaluation of our proposal will be based on feedback gathered from both industry practitioners and academics related to the Service Management field and the demonstrations in several organizations, using for that purpose the software prototype we have implemented. Besides we will evaluate the proposal using the Osterle principles [9] and the feedback from the articles that we aim to submit at scientific conferences.

in section 4 we describe the theoretical Background for this research; in section 5 we provide an overview over the related work; in section 6 we explain our proposal in detail making clear how do we intend to solve the problem; in section 7 we introduce the demonstration step from our research methodology; in section 8 we explain how we plan to evaluate our proposal in terms of the evaluation process and evaluation criteria, and finally in section 9 we describe the communication step of our research methodology and we conclude in section 10 with the expected contributions of our work.

2. Research Methodology

Our research was conducted using the Design Science Research Methodology (DSRM) that aims to create and evaluate IT artifacts intended to solve identified organizational problems [10]. These artifacts include constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices) and instantiations (implemented and prototype systems). Additionally, DSRM established seven guidelines [10]:

 Design as an Artifact – Produce a viable artifact in the form of a construct, a model, a method, or an instantiation. The artifacts to be developed in this thesis are described in section 6 (Proposal);

 Problem Relevance – Develop technology-based solutions to important and relevant business problems. The relevance of this thesis problem is described in section 3.

 Design Evaluation – The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods (section 8);

 Research Contributions – Provide clear and verifiable contributions (section 10).

 Design as a Search Process – The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment. Progress is made iteratively as the scope of the design problem is expanded. As means, ends, and laws are refined and made more realistic, the design artifact becomes more relevant and valuable.

 Communication of Research – The research must be presented effectively to technology-oriented as well as management-oriented audiences (section 9).

DSRM includes the following phases [11]:

 Objectives Definition – Infer the objectives of a solution from the problem definition and knowledge of what is possible and feasible. The objectives can be quantitative, e.g., terms in which a desirable solution would be better than current ones, or qualitative, e.g., a description of how a new artifact is expected to support solutions to problems not hitherto addressed (section 1).

 Design and Development – Create the artifact. Such artifacts are potentially constructs, models, methods, or instantiations (each defined broadly) or “new properties of technical, social, and/or informational resources”. Conceptually, a design research artifact can be any designed object in which a research contribution is embedded in the design. This activity includes determining the artifact’s desired functionality and its architecture, and then creating the actual artifact (section 6);

 Demonstration – Demonstrate the use of the artefact to solve one or more instances of the problem. This could involve its use in experimentation, simulation, case study, proof, or other appropriate activity (section 7).

 Evaluation – Observe and measure how well the artefact supports a solution to the problem. This activity involves comparing the objectives of a solution to the actual observed results from using the artefact in the demonstration (section 8):

 Communication – Communicate the problem and its importance, the artifact, its utility and novelty, the rigor of its design, and its effectiveness to researchers and other relevant audiences, such as practicing professionals, when appropriate (section 9).

This research methodology has been chosen because DSRM is appropriate for research that seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts. DSRM is also active with respect to technology, engaging in the creation of technological artifacts that impact people and organizations [10].

3. Research Problem

This section covers the "Identify problem & motivate" step of the DSRM process [11], where we recognize that the absence of updated organizational models focused on the real time discovery of services and processes constitutes an important business problem that must be addressed. It’s usual that within the execution of a service we need to execute several other services either between different departments within the same organization or between different organizations, as we can see illustrated in figure2.

Figure 2. Cross-departmental and cross-organizational services can be performed within the execution of a service from the organizational catalogue of services

We can see portrayed at figure 2 a vision of a business process as a sequence of services that several actors perform to each other in order to accomplish a final goal that is the final result of the process. Those services can be executed by actors from different departments within the same organization or from different organizations. Our research problem is to discover those business processes and get real time organizational models that can portray them.

We know from the industry that discover the processes in an organization has some challenges. In several cases people don’t know in each part of a process they are inserted in and it’s common to have ad-hoc methodologies for process elicitation. Interviews with workers for process discovery can also not portray what is really performed in their daily work.

The problem of not having real time organizational models representing processes and all the cross-departmental and cross-organizational interactions necessary to carry on those processes is supported in [4] where the author presents the concept of Service Mining based on the evidences that cross-organizational event data cannot be easily shared, messages exchanged between services tend to be structured, service-orientation continues to be the predominant implementation paradigm and that the most substantial efficiency gains can often only be achieved across different organizations [4].

of possible deviations from the previously designed model, avoiding potentially harmful situations for the organization. Besides, if we register in the real time model the times and other measures related to service executions we can enhance services that reveal weaknesses, which cannot be properly performed if we do not have real time organizational models.

4. Theoretical Background

Stated the problem of not having real time organizational models for dealing with services and processes, in this section we introduce the theoretical tools that support our approach to face the problem..

4.1 Enterprise Ontology

This section describes the Enterprise Ontology (EO) concepts that will be used throughout the thesis. EO provides us an interesting approach to organizations that allows us to have a powerful insight about the essence of their operations. In other words, EO provides an insight that is completely independent of the organization’s realization and implementation [15]. Being an ontology, EO supply a basis for the common understanding of an area that has interest to a community of people who may have a different cultural backgrounds and who may not know each other at all [15]. EO is supported by a theory named Ψ (PSI) Theory.

4.1.1 Ψ (PSI) Theory

The Ψ-theory is the theory that underlines the notion of enterprise ontology [15]. It has 4 axioms namely the Operation Axiom, the Transaction Axiom, the Composition Axiom and the Distinction Axiom and 1 theorem which is the Organization Theorem.

Operation Axiom

Figure 3. Graphical representation of the Operation Axiom

Figure 3 exhibits the operation axiom graphically. The symbol for coordination is the disc, the symbol for actor roles is the box, and the symbol for production is the diamond [15]. The plain arrow from the actor’s box to the C-world disc expresses that actors perform C-acts. The dashed arrow from the C-world disc to the actor’s box expresses that actors take account of the state of the C-world when being active [15]. Likewise, the plain arrow from the actors box to the P-world diamond expresses that actors perform P-acts, and the dashed arrow from the P-world diamond to the actors box expresses that actors take account of the state of the P-world when active [15]. Using the notions of actor roles, C-acts/facts, and P-acts/facts, a full abstraction is made from theirs particular implementations. In this way, the particular subjects that fulfil the actor roles at a particular time, the particular way in which C-acts are performed, and the particularly way in which P-acts are performed are all abstracted [15].

Transaction Axiom

The Transaction Axiom makes clear how the coordination acts and the production acts mentioned in the Operation Axiom relate with each other. The Transaction Axiom states that coordination acts are performed as steps in universal patterns [15]. These patterns, also called transactions, always involve two actor roles and are aimed at achieving a particular result [15]. A transaction evolves in three phases: the order phase (O-phase for short), the execution phase (E-phase for short), and the result phase (R-phase for short) [15]. One of the two partaking actor roles is called the initiator, and the other is called the executor of the transaction. In the order phase, the initiator and the executor work to reach an agreement about the intended result of the transaction, i.e., the production fact that the executor is going to create as well as the intended time of creation [15]. In the execution phase, this production fact is actually brought about by the executor. In the result phase, the initiator and the executor work to reach an agreement about the production fact that is actually produced, as well as the actual time of creation (both of which may differ from what was originally requested) [15]. Only if this agreement is reached will the production fact come into existence. The moment at which it starts to exist is agreed upon in the result phase by the two actor roles (to be precise, between the two subjects that play the role of initiator and executor, respectively) [15].

Figure 4. The Basic Transaction Pattern marked with red within the Universal Transaction Pattern

Figure 4 illustrates the Universal Transaction Pattern that represents the relations between the coordination acts (request, promise, state, accept, decline, quit, reject, stop, cancel, allow and refuse).

The Basic Transaction Type is represented within the red line of the same figure. That Basic Transaction Pattern is constituted by a request act in which the initiator declares the intention of receiving some result from the executor; a promise in which the executor compromises himself to deliver the requested result, a state where the executor states that he has finished the production of the requested good/service (P-fact) and an accept whenever the initiator agrees with the executor’s produced fact.

the initiator can send a new request or simply quit the transaction. In a similar way, after a reject act the executor can state a new produced fact or can stop the transaction.

However, we just achieve the Universal Transaction Pattern (figure 4) when we consider that a request, a promise, a state and an accept act can be cancelled at any time. In order to illustrate this cancellation patterns we can think for example in a situation in which a customer (initiator) goes to a bakery and requests a loaf to the baker (executor). Cancellation of the request can occur when the customer sees in the shop a new kind of loaf that looks more pleasant to him or her. Normally the baker will be inclined to please the customer and thus will allow the cancellation. From the state “allowed” that is then reached, the customer quits the transaction. After that she or he can start immediately a new one. The baker may, however, refuse if the transaction has already took place two days ago. The state “refused” is a terminal state for the cancellation meaning that the C-fact requested remains the case [15]. A similar reasoning apply for the cancellation of a promise act, state act and accept act.

Composition Axiom

The Composition Axiom of the Ψ-theory states that every transaction is enclosed in some other transaction [15]. This axiom provides the basis of a well-founded definition of the notion of business process, stating that a business process is a collection of causally related transaction types, such that the starting step is either a request performed by an actor role in the environment (external activation) or a request by an internal actor role to itself (self-activation) [15]. Every transaction type is represented by the complete transaction pattern [15].

Distinction Axiom

The Distiction Axiom of the Ψ-theory states that there are three distinct human abilities playing a role in the operation of actors, called performa, informa and forma. These abilities regard communication, creating things, reasoning, and information processing [15].

The ability that deals with the form aspects of communication and information is called forma like uttering and perceiving of sentences in some language, the syntathical analysis of such sentences, coding schemes, transmission of data, storage and retrieval of data or documents. The informa ability abstracts the form aspects and is concerned with the content aspects of communication and information as sharing of thoughts between people, the remembering and recalling of knowledge and reasoning [15]. The performa ability concerns the bringing about of new, original things, directly or indirectly by communication as commitments, decisions and judgements.

Organization Theorem

The Organization Theorem states that the organization of an enterprise is a heterogeneous systems that is constituted as the layered integration of three homogeneous systems: the B-organization (from Business), the I-organization (from Intellect) and the D-organization (from Document) [15]. Each one of the layers supports the other, namely the D-organization supports the I-organization and the I-organization supports the B-organization [15]. All these three homogeneous systems are in the category of social systems, which means that they are similar in what regards coordination, differing only in the kind of production: the production in the B-organization is ontological, the production in the I-B-organization is infological, and the production in the D-organization is datalogical [15]. Examples of datalogical production acts are storing, copying, transmitting of documents or data. Acts such as reasoning, computing, deriving, or reproducing knowledge are examples of infological production acts and the acts concerning the creation of original new things, such as creating material products or making judgments are examples of ontological production acts [15].

4.2 The DEMO Methodology

The DEMO methodology describes a systematic way to develop enterprise ontologies. The ontological knowledge of the organization is expressed through aspect models namely the Construction Model, the Process Model, the Action Model, the State Model.

Figure 7. The ontological aspect models

Construction Model

The Construction Model (CM) specifies the identified transaction types and the associated actor roles, as well as the information links between the actor roles, as well as the information links between the actor roles and the information banks (the collective name for production banks and coordination banks) [15].

Process Model

The Process Model (PM) contains the specific transaction pattern of the transaction type, for every transaction type in the CM [15]. The PM is put just below the CM in the triangle because it is the first level of detailing of the CM, namely the detailing of the identified transaction types [15].

Action Model

The Action Model (AM) specifies the action rules that serve as guidelines for the actors in dealing with their agenda. It contains one or more action rules for every agendum type. These rules are grouped according to the actor roles that are distinguished types [15].

State Model

also be viewed as the detailing of a part of the CM, namely the contents of the information banks (coordination and production banks) [15].

5. Related Work

In this section we start by describing the definition of service that is going to be used throughout our research. We continue with a summary of some approaches presented in the lately literature that try to tackle the problem of discovering organizational models with a focus on processes and services, namely process mining, service mining and DEMO Engine.

5.1 Enterprise Ontology Based Service Definition

In this research we will adopt the definition of service that is based on Enterprise Ontology. This definition, purposed in [12] states that a service is a universal pattern of coordination (c-acts) and production acts (p-acts), performed by the executor of a transaction for the benefit of its initiator, in the order as stated in the standard of a transaction. When implemented it has the ability to:

- Get to know the coordination facts produced by the initiator;

Figure 8. The Standard Transaction Pattern (Service elements are inside the green line) [12]

The provided service definition is generic enough to hold for two kinds of actor, human actors and IT systems and three kinds of productions acts, namely datalogical, infological and ontological [12]. For both human actors and IT systems, we can distinguish between communication acts and production acts on the datalogical, infological, and ontological level as described in the Organization Theorem. The Enterprise Ontology based service definition allows us to distinguish between six types of services:

5.2 DEMO-based SLA

Mendes & Mira da Silva defined an SLA using EO terms [13]. They stated that a service level agreement is the proposition that two actors (initiator and executor) build together in the O-phase of any ontological transaction. This proposition is clarified by informative acts.

Also these SLAs have five elements, entity responsible for achieving the SLA, service, target, price and penalty. These elements can be all retrieved by using the correct DEMO models. Figure 9illustrates the connection between SLA elements and DEMO models.

Figure 9. Service Level Agreement proposal and relation to Enterprise Ontology [13]

The correlation is possible because, in one hand the EO theory describes, very formally, the interactions that happen between customer and provider and in the other hand Service Level Management acts as the interface between customer and provider. And by using the solid basis of EO we can formalize the SLA definition and achieve better representations of the SLA.

5.3 Process Mining

Figure 10. The three basic types of process mining explained in terms of input and output.

5.4 Service Mining

Web services are an established paradigm for architecting and implementing business collaborations within and across organizational boundaries [14]. Web Services provided by different organizations can be inter-connected in order to implement business collaborations, leading to composite web services. Plus, the autonomous nature of and the fact that they are loosely coupled makes it important to monitor and analyse their behaviour. This is called Service Mining [8].

Service Mining deals with the application of process mining techniques to services [8]. The distributed nature of services makes the design and analysis of service oriented systems that support end-to-end business processes harder [8].

The Service Mining challenges are highlighted with two questions: 1. How to correlate process instances? [8];

2. How to analyse services out of context? [8];

The first question emphasizes the problem that arises when instances from different services need to be related, for instance when one customer order may relate to several deliveries in another service [8].

context may differ from the performance and correctness of the same service in another context [8].

5.5 DEMO Engine

In a recent research Pedro Matos de Carvalho proposed the DEMO Engine, which is a web-based software that registers all the coordination acts involved in a service exchange and make them visible at any time to the stakeholders. The system was proposed for improving service quality but it has the ability to discover the organizational catalogue of services as well [20].

5.6 Critical analysis

In this section we provide a critical analysis to the approaches that we early introduced, namely process mining, service mining and the DEMO Engine.

Process mining by having a kind of process tunnelling vision is not aware that besides individual processes can have no problems when analysed in isolation, deadlocks can occur when we consider all the services involved within a process instance [8]. In our research we plan to discover the chain of service executions that take place as consequence of an initial service request, taking into account the different process instances that although belonging to possibly different service, share a common execution path.

Besides, by having just one common system for executing the business processes it is expected that our software prototype presents more accurate results than process mining once that all the necessary process information is registered in just one shared platform which can be used by different organizations, leading to the discover of accurate cross-organizational business processes.

Our research is focused on the concept of Enterprise Ontology-based services which means that the focus is not just on web services as traditionally is the case of Service Mining. By considering Enterprise Ontology-based services we are stating that we are interested in those services performed by both humans and machines. We also are interested in services that can have as result an ontological production (as a decision), an infological production (as a calculation result) and a datalogical production (as data storage).

6. Research Proposal

This section corresponds to the “Design & Development” step of the Design Science Research Methodology (DSRM). To solve the problem of not having real time organizational models focused on services and processes, that was described in section 3 we propose to use DEMO to simplify the discovery of the chain of Enterprise Ontology-based services that take place as consequence of the execution of a particular service from the service catalogue, in the cases that the accomplishment of a service is dependent on the execution of other internal services like cross-departmental services, or other cross-organizational services (see the example stated in figure 11).

We will develop a web-based system for keeping real time organizational models of the organizational business processes and services. We also support our instantiation with DEMO-based SLAs (described in section 5.2) once that by having a Service Level Agreement for each service, we are able to collect measures specified in those SLAs so that we can enhance services that reveal weaknesses.

Figure 11. DEMO Process Model that shows the services (in green) that constitute the process for getting a program admission.

we just need the service executed by the admitter role and we do not need the involvement of the admission approver anymore.

We implemented in our software prototype the universal transaction patterns described within Enterprise Ontology because they can show us the chain of Enterprise Ontology-based services that are executed among actor roles when a given service from the catalogue of services is requested, as well as the state of each of those services. Performing service mining on those Enterprise Ontology-based services allow us to discover services that can be executed by both humans and machines. Besides, those Enterprise Ontology-based services are able to support ontological (as decisions), infological (as calculations) and datalogical (as storing data) acts.

By registering in our web-based system the way services are executed in real time by actor roles one can easily discover both the organizational service catalogue and an updated organizational model that portrays for each service from the catalogue of services, the other services that must also be executed in order to finish with success the first one. In other words, our web-based system allow us to keep real time organizational models of processes and services.

In those cases where organizations already have a model of the way their services are executed, there is clear opportunity to perform conformance checking and verify if the service executions are or are not following the model. Besides, by registering the times and other measures related to service executions we can enhance services that reveal weaknesses.

Summing up, the proposed web-based system, which is considered an instantiation by our research methodology, will allow us to:

 Discover the updated organizational catalogue of services;

 Discover real time organizational business processes that implement the services from the catalogue of services;

 Discover which coordination acts and production acts have been performed so far within a service execution;

 Discover opportunities for service improvement using gathered data from the web-based system and negotiated in the DEMO-based Service Level Agreements;

Our proposal can be seen as an approach based on the strong theoretical background of Enterprise Ontology & DEMO to deal with the complexity of discovering the chain of services that must be performed between the several actor roles involved, in the context of organizational business processes.

7. Demonstration

This section corresponds to the “Demonstration” step of Design Science Research Methodology (DSRM). To demonstrate our proposal we plan to apply the proposed prototype to a real world organization. Using real world actors, services and Service Level Agreements we expect to contribute positively to a better understanding of how the execution of the services from the service’s catalogue are correlated with other cross-departmental and cross-organizational services.

7.1 Prototype

In order to demonstrate our proposal in a real organization, we are developing a web-based prototype that implements the universal transaction patterns (the standard transaction patterns plus the cancellation patterns) described in Enterprise Ontology. Our software prototype also implements SLA and mines the Enterprise Ontology-based services that are carried on within the execution of organizational business processes. This prototype is being developed using the OutSystems Agile Platform (http://www.outsystems.com).

At this moment, as we try to find a company where we can demonstrate our proposal and as we keep developing some aspects of our web-based prototype we already have implemented some functionality that allow us to simulate a fictional scenario.

7.2 Fictional scenario

The fictional case takes place in a bank and describes a situation where a client goes to his bank and asks for credit. In this situation we assume that we have two actor roles involved in the bank, namely the bank teller role that is implemented by an actor who faces the customer and asks him for specific documentation, and the credit approver role which is the responsible for evaluating and deciding about the credit requests.

Figure 12. Screenshot of the Service Catalogue for the fictional bank

Figure 13. Screenshot after the promise of a Credit Service Request

8. Evaluation

This section explains how we’ll proceed in the “Evaluation” step of DSRM. With this assessment we intend to evaluate how well our proposal supports the solution of the problem stated. Our evaluation method has several steps. We will start by implement our theoretical proposal in a web-based software prototype capable of discovering real time business processes and services using the Enterprise Ontology and DEMO concepts, and evaluate whether we can or cannot implement our theoretical proposal in software logic; afterwards we will interview both service managers and business process managers to assert the proposal utility and to improve our web-based system with the provided feedback; we will then perform field studies where we intend to apply the prototype in real organizations; finally we will submit papers at international conferences and journals for peer review and additionally we will use the Osterle et al. principles [9] to evaluate our research.

8.1Implementation of our theoretical proposal in a web-based system

8.2Interviews

We intend to interview experts from the business process and service areas so we can use their feedback to improve our web-based system. In fact we have already interviewed a business process manager at a portuguese private company with more than 170 IT consultants. He provided us feedback that will be used to improve our system and even commented that his company developed recently a system similar to ours to create models for document what he called “random processes” within their client companies with the goal of automating those processes later. The fictional demonstration described in section 7 was already made in front of that business process manager. We have already arranged other interviews for the beginning of 2014 and we plan to do more within the year.

8.3Field studies

In order to solve the problem of the absence of real time organizational models that portray services and business processes for specific real life contexts, we plan to evaluate our web-based system in real organizations. The expected results for those organizations can be different according to their own features. For those organizations that are not used to monitor and analyse their business processes and services our intervention can lead to the initiation of works in what concerns business processes and services analysis. For the other organizations that already have thought and applied strategies for improving their models regarding business processes, we can perform conformance checking and verify if the pre-established models are actually used in the daily operations.

8.4Paper submission

We also plan to evaluate our work with feedback gathered from the reviews of our submissions at international conferences and journals. At the moment we have already submitted an article at a conference (section 9).

8.5Osterle et al. principles

In order to evaluate the research Osterle et al. proposed four principles [9]: - Abstraction: the artifact must be applicable to a class of problems.

- Originality: the artifact must substantially contribute to the advancement of the body of knowledge;

- Justification: the artifact must be justified in a comprehensible manner and must allow validation;

- Benefit: the artifact must yield benefit, either immediately or in the future for the respective stakeholder groups.

Those principles are fundamental to evaluate researches that use DSRM. Next, we will present the evaluation of the proposed artifact using this framework. This evaluation is based on the feedback received with academics and practitioners.

- Originality: the artifact we propose can be contextualized with the recent research of Pedro Matos de Carvalho (section 5). Besides the author’s proposed system can discover the organizational catalogue of services, it was not able to discover the organizational business processes, that is the chain of Enterprise Ontology-based services that take place as consequence of the execution of a particular service from the catalogue of services.

- Justification: the artifact will be justified by all the evaluation process described in this section. The related work and theoretical background we present in sections 4 and 5 further contribute to the relevance of this principle;

- Benefit: the artifact provides a way to discover real time organizational models regarding services and business processes. Consequently, it is expected to enhance organizational performance and awareness as well as to contribute to business process reengineering initiatives.

9. Communication

This section describes the "Communication" step of the DSRM process, where we will communicate our proposal, its demonstration and evaluation. Hence, besides the thesis, we will submit articles to international conferences and journals where our work will be subjected to peer evaluation.

In fact, we have already written and submitted to the 4th Enterprise Engineering Working Conference (EEWC 2014) 1 paper with the title “Improving Service Quality using DEMO” that addresses the functionality of our prototype dealing with the record and visibility of the state of each service execution.

10.Conclusion

The service sector is the largest economy sector and is the driver for value creation in modern organizations. In order to gain competitive advantages over their competitors, organizations collaborate performing services to each other. There is also collaboration between the different actor roles inside the same organization. In order to attend customer requests for services presented in the catalogue of services, the actor roles perform services between them. Those services are described within Enterprise Ontology theory, and they all share the same theoretical foundation either they are executed by humans or machines.

In this research we present a proposal to solve the absence of real time organizational models regarding organizational business processes and services. We aim at developing a web-based prototype that is able to mine the chain of Enterprise Ontology-based services that take place as consequence of the execution of a particular service from the service catalogue. We use DEMO so we can show simplified but conceptually strong models that portray organizational business processes. We also use the Enterprise Ontology-based service definition to support our proposal once that all the services share the same essence independently of their concrete implementation. Service Level Agreements are also part of the implementation so that we can gather measures like time to check for opportunities for service enhancement.

The expected contributions of our research are the implementation of a web-based prototype that is able to discover real time organizational business processes and services as well as an approach to service mining focused on the interactions between the several actors.

This research follows the Design Science Research Methodology since it can be applied in the context of Information Systems through the creation of IT artifacts that solve real-world organization problems.

In the near future we intend to apply and validate our proposal in a private company as well as submit more articles so that we can get appraisal from the scientific community.

References

[1] MCCORMACK, Kevin P.; JOHNSON, William C. Business process

orientation: gaining the e-business competitive advantage. CRC Press, 2010.

[2] KOHLBACHER, Markus; REIJERS, Hajo A. The effects of process-oriented organizational design on firm performance. Business Process

Management Journal, 2013, 19.2: 245-262.

[3] VAN DER AALST, Wil, et al. Process mining manifesto. In: Business

process management workshops. Springer Berlin Heidelberg, 2012. p.

169-194.

[4] VAN DER AALST, Wil MP. Challenges in service mining: record, check, discover. In: Web Engineering. Springer Berlin Heidelberg, 2013. p. 1-4. [5] ZHENG, George; BOUGUETTAYA, Athman. Service mining on the

Web.Services Computing, IEEE Transactions on, 2009, 2.1: 65-78.

[6] VERGIDIS, K.; TURNER, C. J.; TIWARI, A. Business process perspectives: Theoretical developments vs. real-world practice. International

Journal of Production Economics, 2008, 114.1: 91-104.

success: Seeking a valid and reliable framework. Business process

management Journal, 2011, 17.1: 127-146.

[8] VAN DER AALST, Wil. Service mining: Using process mining to discover, check, and improve service behavior. 2012.

[9] ÖSTERLE, Hubert, et al. Memorandum on design-oriented information systems research. European Journal of Information Systems, 2010, 20.1: 7-10. [10] HEVNER, Alan R., et al. Design science in information systems

research. MIS quarterly, 2004, 28.1: 75-105.

[11] PEFFERS, Ken, et al. A design science research methodology for information systems research. Journal of management information systems, 2007, 24.3: 45-77.

[12] ALBANI, Antonia, et al. Enterprise ontology based service definition.

In: 4th International Workshop on Value Modeling and Business Ontologies

(VMBO), The Netherlands. 2009.

[13] MENDES, Carlos; MIRA DA SILVA, Miguel. DEMO-Based Service Level Agreements. In: Exploring Services Science. Springer Berlin Heidelberg, 2012. p. 227-242.

[14] ALONSO, Gustavo, et al. Web Services: Concepts, Architectures and

Applications. Springer Publishing Company, Incorporated, 2010.

[15] DIETZ, J. L. G. Enterprise Ontology-Theory and Methodology. 2006. [16] JOHN W. CRESWELL. Research design: Qualitative, quantitative, and

mixed methods approaches. Sage, 2009.

[17] PRIES-HEJE, Jan; BASKERVILLE, Richard; VENABLE, John R. Strategies for design science research evaluation. 2008.

[18] ÖSTERLE, Hubert, et al. Memorandum on design-oriented information systems research. European Journal of Information Systems, 2010, 20.1: 7-10. [19] HEVNER, Alan R., et al. Design science in information systems

research. MIS quarterly, 2004, 28.1: 75-105.

Appendix.

As future work, we will iterate again over our web-based protorype so we can perform bug fixes and improve its look & feel. Then we plan to demonstrate the system in a traditional DEMO fictional scenario – the Pizzeria and in a field study. After that we will interviews experts and evaluate our prototype using the gathered feedback. Finally we will write a paper and conclude the dissertation. All the planed start and finish dates or the activities mentioned in figure 14 can vary because some of them rely upon external participants.