COMPARING SERVICES USING DEMO

Carlos Mendes, João Ferreira and Miguel Mira da Silva

Instituto Superior Técnico, Technical University of Lisbon, Avenida Rovisco Pais, Lisboa, Portugal

Keywords: Service Identification, Enterprise Ontology, DEMO, Service Catalog.

Abstract: The services industry is currently the fastest growing part of economic activity in the world and some

companies are changing their business models from product manufactures to service providers. These

companies acknowledged the role of services as connection points between them and their customers. Still

some service providers have a perception of what their customers want that differs from the real expected

service. In this paper, we use Design & Engineering Methodology for Organizations to compare two lists of

services provided by a Human Resources department: one based on a description given by the head of the

department and another based on the customers that use the department services. The differences between

the two lists identify the gap between the customers’ expectations and the provider perceptions of those

expectations.

1 INTRODUCTION

Over the past few years, organizations have faced

the challenge of providing services efficiently to

their clients, whether they are enterprises or other

departments within the same organization. Besides

this constant pressure, there has been another

growing business unit demand for new services and

higher service levels (O´Loughlin, 2009). Nowadays

services mean jobs and growth, but the companies

that have been leading the charge lack a strong

conceptual foundation (Chesbrough and Spohrer,

2006). This lack contributes to the gaps

(Parasuraman et al., 1985) that reduce the services

quality for, without a solution to specify it, it is

difficult for the service providers and their

customers to align their expectations about the

services quality.

We believe that Enterprise Ontology (EO)

(Dietz, 2006) is a theory that can be the beginning of

this needed theoretical background. Therefore, we

are using it and the corresponding methodology, the

Design & Engineering Methodology for

Organizations (DEMO), as foundation for our most

recent proposals.

In this paper, we show how to identify the

possible mismatch between what a provider thinks it

provides to its customers and what is actually

supplied to customers, thus emphasizing the

importance of a correct identification, definition and

documentation of services, for instance, in a Service

Catalog. The design and development of a Service

Catalog involves multiple activities such as the

correct identification of the services that will be

defined in this document. However, nowadays, there

are no formal methods that allow to correctly

perform this step (Hubbers et al., 2007).

Our study was conducted using the Design

Science Research Methodology (DSRM) that aims

at creating and evaluating Information Technology

(IT) artifacts intended to solve identified

organizational problems, in which these artifacts

may extend the knowledge base or apply existing

knowledge in new innovative ways. In this paper,

we present a research that is focused in the second

option (i.e. apply existing knowledge in new

innovative ways). This research method includes the

following phases, described in detail in (Peffers et

al., 2008): problem identification, objectives

definition, design and development, demonstration,

evaluation and communication.

This paper is structured as follows. We will start

by describing the problem concerning the

identification of services in Section 2. Next, we

provide a brief overview of the literature on ITIL

and CMMI-SVC service models, on current

methodologies to identify services and on DEMO

methodology (Section 3). Subsequently, we explain

our DEMO-based proposal to identify services

(Section 4) and present an example, based on a real

528

Mendes C., Ferreira J. and Mira da Silva M..

COMPARING SERVICES USING DEMO.

DOI: 10.5220/0003719805280537

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (SSEO-2011), pages 528-537

ISBN: 978-989-8425-80-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

organization, where we applied our proposal

(Section 5). We evaluated the obtained results using

an empirical method and employees’ feedback

(Section 6) and we explain what we have learned

from this project (Section 7). Finally, we present our

conclusions (Section 8).

2 PROBLEM STATEMENT

While the Service Catalog is an element that is

increasingly important for organizations, its

implementation poses several risks (Hubbert and

O'Donnell, 2009). One of the problems currently

affecting organizations, and that this document

proposes to solve, is the struggle to be able to

identify what services they provide to achieve

business goals and outcomes. Despite the effort

made in recent years, a unified methodical approach

for service identification has not yet been discovered

(Hubbers et al., 2007). The incorrect identification

and definition of IT services, due to their structural

role, will affect other processes since they are

largely based on these services leading to a Service

Catalog that is ineffective and provides no real value

to any part of the organization (O´Loughlin, 2009).

If the services are not identified, defined and

catalogued, or due to an ineffective management of

customer expectations, overpromising and others,

the communication about the service will not match

the actual service delivery. Consequentially, the

customers may perceive the services differently

from what is communicated by the provider

(Zeithaml and Bitner, 1996). This section

corresponds to the problem identification and

motivation phase of DSRM.

3 RELATED WORK

Since this document focuses on the identification of

services, it is important to define what a service is.

We give a brief overview of the multiple existent

definitions of service and by DEMO methodology,

used in our proposal. Next, we analyze both ITIL

and CMMI-SVC, each containing processes that

deal with Service Catalogs and service identification

as well as two of the most studied service

identification approaches by researchers: Business

Components Identification and Service Oriented

Architectures. Finally, we analyse DEMO, used in

our proposal.

3.1 Definition of Service

The term “service” has many different definitions,

depending on the context in which it is being used

(O'Sullivan, 2006). Several definitions of service are

based on technology. Some definitions of electronic

services (or e-services) use the Internet and/or

workflow as a conduit to new revenue or task

completion. A web service has been described as an

aggregation of functionality published for use.

However, these definitions raise some concerns:

they are focused on technology and they tend to

ignore conventional services, in what is called “web

service tunnel vision”. It is important to notice that

services are not just about technology and also

include nontechnology aspects (Jones, 2005).

In the service marketing literature, there is a

wide range of definitions of what a service entails.

Usually, a service is defined as an intangible set of

benefits or activities that are sold out by one party to

another. Its main features are: intangibility,

heterogeneity, simultaneously produced and

consumed and perishability (Zeithaml and Bitner,

1996).

In (Albani et al., 2009) the definition of service

is based on the standard transaction pattern proposed

in Dietz’s DEMO (Dietz, 2006). Though a service

has many similarities with a transaction in Enterprise

Ontology, they are not equal: A service is a

universal pattern of Coordination and Production

acts, performed by the executor of a transaction for

the benefit of its initiator, in the order as stated in the

standard pattern of a transaction. When implemented

it has the ability:

 to get to know the Coordination facts

produced by the initiator;

 to make available to the initiator the

Coordination facts produced by itself.

This definition of service just given is a very

generic one, since it holds for two kinds of

providers: human actors and IT systems. Services

executed by human actors and IT systems only differ

in the way they are implemented; human services

are implemented by human beings, whereas IT

services are implemented by IT systems (Albani et

al., 2009). These systems assist human actors in their

activities; therefore parts of a human service may

also be executed by IT systems.

3.2 Service Identification Techniques

As said, although a formal and unified method to

identify services has not been discovered yet, some

COMPARING SERVICES USING DEMO

529

approaches have been proposed over the years to

solve this issue.

Information Technology Infrastructure Library

(ITIL) (Bon, 2007) and Capability Maturity Model

Integration for Services (CMMI-SVC) (CMMI for

Services, version 1.3, 2010) provide a set of best

practices for service provider organizations. While

ITIL aims at controlling and managing all aspects of

IT related operations, CMMI-SVC is a maturity

model and a process improvement approach for

general service providers. Even with different focus,

both have specific areas which deal with Service

Catalogs and, consequently, with service

identification. However, they mostly deal with what

processes should be implemented, and not so much

with how they can be implemented, not providing a

specific process to identify services.

In order to promote software reuse, Component-

based Software Engineering (CBSE) techniques

have been adopted to ease the development of large-

scale complex information systems (Fan-Chao et al.,

2005). As described in (Wang et al., 2005), there are

three kinds of service identification techniques,

based on components: Domain Engineering based

methods, CRUD Matrix based methods and

Cohesion-Coupling based Clustering Analysis

methods. Instead of identifying services directly,

these identify the components and, since each

component provides services to the exterior, they

claim we can also identify its services. Nevertheless,

a specific process to perform this task is not

presented.

Service Oriented Architecture (SOA) is an

architectural approach for designing, architecting

and delivering enterprise applications that support

business operations as a set of meaningful services.

Many researches are suggesting various

methodologies to guide the migration to SOA, each

with its own approach to service identification. In

(Terlouw and Dietz, 2010) there is a review of some

SOA methodologies such as SOMA (Arsanjani,

2008) and SOAF (Erradi et al., 2006). These

methodologies provide a solid basis to achieve SOA,

but they do not describe all phases very thoroughly

or clearly. Moreover, they are technology-based,

focusing on web services.

3.3 DEMO

Design & Engineering Methodology

forOrganizations (DEMO) is a methodology for

modeling, (re)designing and (re)engineering

organizations and networks of organizations (Dietz,

2006). DEMO aims to develop high-level and

abstract models of the construction and operation of

organizations, independently of their actual

implementations, by focusing on the communication

patterns between human actors, i.e., models of

organizations from a responsibility and

communication oriented perspective. The theory that

underlies this methodology is called Enterprise

Ontology and consists of four axioms: Operation,

Transaction, Composition and Distinction.

The Operation axiom states that an organization

consists of human beings, in their role of social

individuals or subjects, who achieve their goals by

performing acts. A subject fulfilling an actor role,

which is defined as a particular amount of authority

and responsibility, is called an actor. An actor

performs two kinds of acts: Production acts (P-acts)

and Coordination acts (C-acts). On the one hand, by

performing P-acts, the actors contribute to bringing

about the goods or services that are provided or

delivered to the environment of the organization. On

the other hand, by performing C-acts, actors enter

into and comply with commitments and agreements

towards each other regarding the performance of P-

acts. The result of successfully performing a P-act is

a Production fact or P-fact, and the same applies to a

C-act, creating a Coordination fact or C-fact.

The Transaction axiom states that C-acts are

performed as steps in a universal pattern, called

transaction, to successfully complete a P-act. Each

transaction distinguishes two actor roles: the

initiator, who starts the transaction and might

complete it, and the executor, who is responsible for

the performance of the P-act and the creation of the

respective P-fact. A transaction evolves in three

phases: the Order phase (O-phase), the Execution

phase (E-phase) and the Result phase (R-phase). In

the Order phase, the initiator and the executor

negotiate about the intended result of the transaction

(P-fact that the executor is going to create); in the

Execution phase, the P-fact is produced by the

executor; and finally, in the Result phase, the

initiator and the executor negotiate and discuss the

result of the transaction (P-fact actually produced).

The Composition axiom describes how these

transactions can interact. According to this axiom,

any transaction is either enclosed in some other

transaction, initiated by an external party to the

organization or a self-activated transaction. If there

is an enclosed transaction, an information

dependency usually exists between the enclosing

and the enclosed transaction.

The Distinction axiom acknowledges three

human abilities called Performa, Informa and Forma

which are exerted both in C-acts and P-acts. The

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

530

Forma ability concerns the form aspects of

communication and information (Datalogical layer);

the Informa ability is related to the content aspects

of communication and information, fully abstracting

from the form aspects (Infological layer); the

Performa ability involves the creation of new,

original things, directly or indirectly by

communication (Ontological layer). This last ability

is considered as the essential human ability for doing

business, and is the one in which DEMO focuses on.

We just gave a short summary of the Enterprise

Ontology and discussed the parts relevant for our

service identification proposal. A complete overview

of the theory is available in book (Dietz, 2006) and

many others publications (List:

http://www.demo.nl/publications/).

4 PROPOSAL

In order to solve the problem described in Section 2,

we intend to use the DEMO methodology to identify

the services provided by organizations, or their

departments, to their customers. Since best practices

cannot help us, because they are too general and do

not specify how to identify services, and the already

existent methods which allow this task are focused

on technology, we decided to use DEMO and the

definition of service based on this methodology,

because it provides abstract and high-quality models

and has a strong theoretical foundation (Huysmans

et al., 2010). Moreover, this methodology focuses on

what really matters, i.e. the business layer, not

considering the implementation details which are

secondary to clients.

We propose to use the following steps, already

defined by DEMO in (Dietz, 2006), to find the

services of an organization:

 Enterprise Description: A textual description

which summarizes the actions performed by

the service provider to fulfill the customer’s

requests;

 Performa-Informa-Forma Analysis:

Identification of the three kinds of human

abilities (Performa, Informa, and Forma)

performed in the context of the organization,

according to the Distinction axiom, using the

text of the previous step;

 Coordination-Actors-Production Analysis:

The identified Performa items are split into C-

acts/facts, P-acts/facts and actor roles who

perform those acts, according to the Operation

axiom;

 Transaction Pattern Synthesis: Identification

of each transaction type, and the corresponding

result, based on the identified acts/facts,

according to the Transaction axiom;

 Result Structure Analysis: Check if there are

any dependencies between the identified

transaction types. Generally, these

dependencies occur when the executor of a

transaction is the initiator of another (inner)

transaction, as already explained in the

Composition axiom;

 Actor Transaction Diagram/Service

Identification: Identification of the initiator

and executor actor roles of each transaction

type. When this mapping between transactions

and actor roles is complete, it is possible to

identify the services provided by the studied

organization;

These steps are based on the EO explained in the

last section and will be further detailed in the

following one. According to the DSRM, this set of

steps is the artifact that we will employ to identify

services; we are using already existing knowledge

(DEMO methodology) to show how to identify

them. This section and the previous one correspond

to the design and development step of DSRM.

5 ACTION

In order to show the feasibility of the DEMO

methodology for service identification, we will

explain its relevant notions on the basis of a small

real-life example, which will allow to increase the

practical relevance of our study and to obtain an in-

depth insight into how DEMO can assist in the

service identification process. This case study aimed

to provide evidence against the importance of well

identified services (for instance, in a Service

Catalog), their definition and service levels. For that,

we decided to study a Human Resources (HR)

department and to identify the services it provided to

the rest of the organization. The study focused on a

European private company, leader in the wines and

spiritual beverages distribution, which we will call

from now on Company X. The head of the HR

department (Gabriela) described the functions and

actions she had to take to perform her job. In

addition, we also interviewed an employee of the

Marketing department (Rosario), in order to identify

what interactions she had with the HR department,

i.e. what services she thought the HR department

provided her. So, the final objective is to prove that

the services a provider thinks it offers differ from the

COMPARING SERVICES USING DEMO

531

perceived services for a customer. This section

corresponds to the demonstration phase of DSRM.

Firstly, we describe the actions undertaken by the

head of the HR department. The starting point to

fulfill this task is called Enterprise Description and

is characterized by producing a text which

summarizes the actions performed by the service

provider, such as the presented below. This text

should be based in all the available documentation

and written by someone who will not be involved in

the task, ensuring the validity of the exercise, but

with enough knowledge about the performed

activities. Due to space limitations, we will just

present the text after applying the first two analyzes.

When the text is written, one should read it

carefully and try to recognize and distinguish

between the Ontological, Infological and Datalogical

actions described, as referred in the DEMO’s

Distinction axiom (see Section 3.3). This step is

called Performa-Informa-Forma Analysis. To do

that, we should define a notation to differentiate

those actions: in this example, we have highlighted

the text, using Black, Dark Gray and Light Gray

colors to identify, respectively, the Ontological,

Infological and Datalogical actions.

The next step concerns the identification of C-

acts/facts, P-acts/facts and actor roles, using the

Performa (Ontological) items identified in the

previous step. We also have considered a notation to

differentiate between them, similar to the one used

in the Operation axiom: square brackets “[” and “]”

to identify actor roles, brackets “(” and “)” to

identify C-acts/facts and angled brackets “<” and

“>” to identify P-acts/facts. This step is called

Coordination-Actors-Production Analysis and here

there is a reduction of the complexity, relatively to

other methodologies, because from now on, we will

only be considering the Ontological actions

identified in this step. The result of applying these

two analyses to the original text is presented below:

The Human Resources (HR) department of

Company X is responsible for the development of the

monthly payroll, management of the vehicles

distribution, infrastructure management, training of

the various employees, recruitment of new

employees, and insurance, among others. It is

constituted by 3 other employees: Vitor, Patricia

and Luisa. Vitor deals essentially with fleet

management, post office and banks, Patricia assists

the Finance department and General Manager(she

is a personal assistant of these 2 areas), and Luisa is

a receptionist who deals with phone calls and Proof

of Deliveries (PODs). They both report to Gabriela,

head of HR.

The recruitment process of Company X starts

when both the [HR] and the General Manager agree

that there is a (need) to <hire> [new employees].

This need can be obtained from previous feedback

given by the responsible for each department. The

recruitment can be internal or external. In case of

internal recruitment, such as internal staff turnover,

someone in a specific area can be <moved> to

another one. However, in case of external

recruitment, it is possible to use the support given by

the [universities] to <hire> a [new trainee] and give

him/her the necessary <training>, or, through

advertisements or [temporary employment

companies], <hire> [someone already established on

the market] and with experience. When there is a

need to hire a new trainee, the HR department of

Company X contacts some specific universities,

according to the function and pre-requisites to

perform that function. After this first contact, some

universities proceed to the selection of resumes,

while others send them all to Company X, which will

select the most promising candidates. Next, these

candidates are directly contacted by Company X to

schedule the first interview with HR. If the candidate

is accepted into the next stage of the recruitment

process, a second interview meeting is scheduled

with the head of the department where the function

will take place. Finally, in case of satisfactory

performance, the candidate is accepted. This

recruitment process based on interviews is similar to

all candidates, whether they are graduates or people

with work experience.

About the fleet management, the [HR] is

responsible for the <rental> of certain types of

vehicles, which will be used by employees with

determined functions. This rental is made to an

[external renting company], and HR has to deal with

distance control, accidents, and further expenses

related to these vehicles (highway, fuel). They

negotiate a contract that has a certain time limit,

and includes various options such as maximum

distance that can be travelled. It is also necessary to

<make an insurance> for the vehicles. After

receiving the vehicles, one must regularly check if

they have (mechanical) problems and if they occur,

the car must be <taken> to a [workshop] for repair.

Exchanging vehicles between drivers to guarantee a

balanced use of each must also be considered. When

the contract is about to end, the vehicle is <taken>

to [inspection] to check if everything is fine.

The <insurance> is also related to HR. For

instance, there are several types of insurance: life

insurance, health insurance, vehicle insurance and

others. In case of a trainee, the work accidents

insurance is the only one to be triggered, if it is a

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

532

temporary contract, it includes health and work

accidents insurance, and if it is a permanent

contract, it includes life, health and work accidents

insurance. In both cases, the HR communicates with

the insurer and Social Security to deliver tax and

documents.

The payroll is determined using the budget that

was established for that year. The monthly salary for

each employee is calculated and pre-determined

from the company politics, and it is affected by

absences, product discounts, among other factors

which will be uploaded to the software that

calculates each month’s salary. To determine every

factor, the head of each department must inform the

HR.

The [HR] <establishes> telecommunications

contracts with specified [operators] to ease the

communication of the employees and checks if these

contracts are fulfilled by the operating company

which affects the monthly payment that has to be

taken. HR is also responsible for the development of

the employees’ vacation map, control of the

documented internal politics of the company and

check if they are being carried out by employees,

and occupational medicine to ensure that some

employees meet certain requirements to perform

some actions.

At the end of every year, the performance

appraisal process is executed, during which the job

performance of each [employee] is <evaluated>. The

[HR] develops specific forms for each department,

which must be filled in by the employees until a

certain date (Self evaluation). After this phase, the

head of each department gathers the feedback given

by their employees and then schedules meetings with

all members to discuss the performance during the

last year.

When the performance appraisal process has

finished, it is time to check if [someone] (needs) a

particular <training session> in a specific subject.

When this need is identified, one tries to identify a

group of employees that also needs the same

training. After that, it is necessary to plan the

training session. This way, the HR starts by checking

the availability of the employees, possible dates to

execute it, text books, proofs of participation and

other logistics steps. In case of internal training, the

HR verifies who, inside the company, has the know-

how to develop that training session, and then, the

chosen employee will be held responsible for

developing the module. In case of external sessions,

the HR also needs to contact an accredited external

company to execute the training session.

The infrastructure management (office equipment,

chairs, tables) and overall function of the

headquarters is conducted by the [HR]. When

employees (need) office equipment, they ask Vitor

for it. Then, he will <order> this equipment in the

office store. When the equipment arrives, the store

sends it to Company X and it is delivered to the

employees. The [HR] also <deals> with the logistics

of the company’s events (Christmas dinner, company

day and answers the employees’ general doubts.

After these analyses, it is time to define the

existent transactions in this text, by clustering the

identified C-acts/facts and P-acts/facts, in what is

denominated by Transaction Pattern Synthesis. The

Transaction axiom can be helpful in this step,

because it guarantees that each P-act/fact or C-

act/fact previously found corresponds to a complete

transaction. Then, for each identified transaction

type, the result type (i.e., the Production fact

created) should be correctly and precisely

formulated, which can be achieved by uniquely

identifying an entity, using variables. This result is

represented in the table below, called Transaction

Result Table (see Table 1).

Table 1: Result table – HR point-of-view.

Transaction Types Result Types

T01 – Hire a new

employee

R01 – Employee E has been

hired

T02 – Rent a vehicle

R02 – Vehicle V has been

rented

T03 – Repair vehicle

R03 – Vehicle V has been

repaired

T04 – Inspect vehicle

R04 – Vehicle V has been

inspected

T05 – Insure a vehicle

R05 – Vehicle V has been

insured

T06 – Insure an employee

R06 – Employee E has been

insured

T07 – Establish

communication contracts

R07 – Telecommunication

contract T has been established

T08 – Evaluate job

performance

R08 – Job performance J has

been evaluated

T09 – Give training

session

R09 – Training session S has

been given

T10 – Fulfill equipment

requests

R10 – Request R has been

fulfilled

T11 – Order and receive

office equipment

R11 – Office equipment O has

been received

T12 – Organize company

events

R12 – Event E has been

organized

After having defined the transaction types and

the respective result types, one must check if there

are any dependencies between the transactions/ P-

facts (results), as the Composition axiom describes.

This step is called Result Structure Analysis and can

be executed by carefully reading the text one more

time. The following dependencies were found:

COMPARING SERVICES USING DEMO

533

 There is a dependency between T01 and T06:

after hiring a new employee, the HR

department has to insure him/her. T06 is

mandatory;

 There is a dependency between T02 and T05:

when a vehicle is rented to an external renting

company, the HR department is responsible

for insuring that same vehicle. T05 is

mandatory;

 T10 depends on T11: in order to fulfill the

employee’s general requests, the HR

department contacts the Office Store to order

the necessary equipment. T11 is optional;

 There are no dependencies involving the

remaining transactions.

After identifying the transaction types, its results

and dependencies, it is time to determine the

environment surrounding the HR department,

considering the organization context. The first model

to be developed is called the Actor Transaction

Diagram (ATD), represented in Fig. 1. In this type

of diagrams, a transaction is represented using a

symbol, more specifically a diamond in a disk,

which contains the respective combination of C-acts

and a P-act. Each transaction is connected to two

gray boxes, representing the initiator and executor

actor roles. The initiator is connected to the

transaction symbol using a solid line, while the

executor is connected to the transaction using a solid

line ending in a black square. These gray boxes refer

to composite actor roles, i.e. elements whose exact

structure is not known. All the environmental

elements, i.e. elements outside the organization that

we are studying, are represented with gray boxes for

that reason. This also means that we can represent

the studied organization with a gray box when

referring to the kernel of the organization, which can

be further specified using elementary actor roles

(represented by white boxes). In this example, for

simplicity reasons, the HR department has been

considered as composite actor role. The gray-lined

rectangle in the back represents the boundary under

consideration.

As depicted in Fig. 1, and following the service

definition based on EO, we can identify four

services provided by the Human Resources

department of Company X, according to Gabriela:

hire a new employee (T01), give a training session

(T09) to Company X’s employees, fulfill requests of

the employees related to general office equipment

(T10) and finally, organize Company X’s events to

its employees (T12).

Figure 1: Actor Transaction Diagram – HR point-of-view.

Until now, we have thoroughly described all

steps to find the services from the HR’s point-of-

view. We will now describe these steps more briefly

in order to find the services provided by the HR

department, but now from the Marketing

department’s point-of-view (customer). After

collecting the textual description and applying the

first two analyzes, Performa-Informa-Forma and

Coordination-Actors-Production Analyzes, we have

obtained the following text:

According to Rosario, when she was hired to

work at Company X, there wasn’t any Human

Resources (HR) department yet. She was <hired>

with the assistance of an external company. She had

a first interview with [Vera Ribeiro] (Marketing

dept.) and an agent of the external company,

followed by a second meeting to discuss the working

conditions and sign documents. The first week on the

job was called Integration Week, when the new

employees can understand what is the done by the

various Company X departments.

Nowadays, regarding the <evaluation process>,

[Rosario] receives emails from the HR containing

the forms that must be used in the self-evaluation

phase, as well as the internal procedures and

politics of the company. About the training sessions,

all the logistics <is arranged> by the [HR], as well

as the management of the number of training hours.

The head of the department is responsible for

informing the HR that a specific training might be

needed.

Every month, she receives the phone bill. Each

employee has a limit that he/she can spend monthly,

and if the limit is overreached, then the [employee]

has to <pay> the difference.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

534

To <schedule> her vacation, [Rosario] needs to

send her proposal to Vera Ribeiro, who analyzes

and approves it or not. Then, Vera Ribeiro sends

the proposal to Vera Martins (Marketing dept.) to

guarantee a consensus between the whole

departments. From here on, the HR is informed.

When she wanted to change her NIB code, she

had to call HR to let them know about the new one

and complete the necessary documents. The same

thing happened when [she] (wanted) to <include>

another beneficiary in her insurance.

In order to correctly calculate her salary, in

case of absences, she has to deliver some documents

to the HR, and then this department proceeds to the

correct discounts. In case of expenses the same

procedure must be followed. When these aspects are

known, the software automatically calculates the

output.

Problems with office equipment <are dealt> with

by [Vitor]. When she wants to send a letter, she

provides it to Vitor, who is now in charge of

delivering it at the postal offices. Letters received at

Company X are delivered to the respective recipients

by Patricia.

After identifying the Ontological activities and

the involved actor roles, we can identify each

transaction and its result, on the Transaction Pattern

Synthesis (see Table 2).

Table 2: Result table – Marketing point-of-view.

Transaction Types Result Types

T01 – Hire a new

employee

R01 – Employee E has been

hired

T02 – Evaluate job

performance

R02 – Job performance J has

been evaluated

T03 – Give training

session

R03 – Training session S has

been given

T04 – Pay

telecommunications

invoice

R04 – Invoice I has been paid

T05 – Schedule vacations

R05 – Vacation schedule S has

been developed

T06 – Change insurance

status

R06 – Employee E has

changed its insurance status I

T07 – Fulfill equipment

requests

R07 – Request R has been

fulfilled

From Rosario’s point-of-view, there are no

dependencies among the identified transactions. The

explanation for this occurrence is due to the fact that

Rosario works at the Marketing department, so, she

does not know how the HR actually performs those

transactions. This step corresponds to the Result

Structure Analysis.

The ATD from the point-of-view of the

Marketing department is represented on Figure 2. As

we can see in Fig. 2, it is possible to identify three

services provided by the HR department of

Company X, according to Rosario: give a training

session (T03), change the status of the insurance

(T06) and finally, fulfill requests of the employees

related to general office equipment (T07).

Figure 2: Actor Transaction Diagram – Marketing

point-of-view.

After analyzing both points-of-view, we can

conclude that there are similarities and differences

between them. On the one hand, we found two

services which are similar, “Give training session”

and “Fulfill equipment requests”. On the other hand,

there were also some mismatches: while in the HR’s

point-of-view we identified “Hire new employee”

and “Organize company events”, from the

Marketing’s point-of-view we found “Change

insurance status”. These differences will be discussed

in the following sections.

6 EVALUATION

After applying our proposal to identify the services

provided by the HR department, from a HR’s point-

of-view and a customer point-of-view, we can

evaluate the obtained results. This way, we used the

Moody & Shanks Framework (Moody & Shanks,

2003) to assess the quality of the Actor Transaction

Diagrams and collect the HR and customer’s

feedback about the results. The evaluation phase of

DSRM is achieved in this section.

To evaluate the quality of the produced models,

we used the Moody & Shanks framework, which has

been empirically tested and is composed by a set of

eight quality factors:

Completeness: refers to whether the model contains

all user requirements. This factor is influenced by

the person who describes the organization or

COMPARING SERVICES USING DEMO

535

department which is being studied. Thus, in the HR

perspective, if the person who described the

department has forgotten to mention some details

about its functions, as consequence, it would not be

possible to identify all the transactions / services.

From the Marketing perspective, it is not possible

for Rosario to identify all the services provided by

the HR, because it depends on what are the main

interactions between the HR and Marketing. For

instance, it is normal that the Marketing employee

did not have any idea about the organization of

events (which was identified as a service by the HR

itself), because in her daily functions, she had never

been involved in this kind of transaction;

Integrity: indicates the extent to which all business

rules have been included in the model. The ATD

does not express any business rules, but it was

possible to gather the dependencies between

transactions;

Flexibility: describes the ease with which the model

can cope with business and/or regulatory change.

One can claim that the ATDs are stable against

changes in the composition of members of the

environment which interact with the HR department,

since these structural changes do not reflect

themselves on the ontological level. For example,

actor roles such as Insurance company and

Workshop, among others, are general enough. From

the HR perspective, there are three dependencies

between transactions that can diminish this aspect.

Contrasting, from the Marketing perspective there

are no dependencies at all;

Understandability: refers to the ease with which

the concepts and structures can be understood. The

produced models were shown to HR and Marketing,

after being developed, and the initial reaction

revealed some confusion. One may find it difficult to

understand the ATD, if not familiar with the

notation; however the reduced number of element

types that composes each model can contribute to a

fast learning;

Correctness: describes the extent to which the

model conforms to the rules and conventions of the

modeling technique. Since the model uses a

diminished number of elements and the basic

transaction pattern, it is possible to easily verify the

accuracy of the ATD model

Simplicity: refers to the extent to which the model

has a minimum number of constructs. Since DEMO

is focused on the Ontological level, there is a

significant reduction on the number of elements

when we consider the original source, in this case

the description, which has several Datalogical and

Infological aspects. For instance, the ATD of the HR

perspective has twelve transactions and ten actor

roles, while the ATD of the Marketing perspective

has seven transactions and four actor roles;

Integration: with respect to this particular case

study, integration is concerned with the extent to

which the two different models can be integrated or

compared to each other. This quality factor depends

on the textual description provided by both parties.

Despite the differences which were found and

explained, there were also some common points

(two services / transactions and several actor roles);

Implementability: denotes the ease with which the

data model can be implemented within the time,

budget and technology constraints. In DEMO

models, we are dealing with the Performa

(Ontological) elements performed by actor roles,

which are implementation independent. So, it is

possible to conclude that DEMO models are not the

best way to represent the implementation details.

The evaluation of the obtained models and results

was also performed by asking for the HR and

Marketing employees’ opinion. In general, the

provided feedback was rather positive, because they

understood the obtained services. Nevertheless, a

general complaint was that our list of services did

not include all the functions the employees perform.

This is due to the already referred feature of DEMO

being implementation-independent, not considering

the Infological and Datalogical activities. If one

revises the textual descriptions of the HR, from both

points-of-view, it is possible to conclude that the

majority of the actions are included on the Forma

and Informa categories (Datalogical or Infological,

respectively). These actions have great potential to

be automated by IT systems (Dietz, 2006). No Actor

role performing Forma or Informa activities can ever

be completely automated, but the effort that these

subjects have to make in fulfilling the role can be

reduced to a minimum.

7 LESSONS LEARNED

After applying the proposal, it is possible to

understand how it can reduce the complexity of

enterprise models: by layering it in three parts, and

focusing only on the part which refers directly to the

creation of new original facts (Ontological layer).

Despite these advantages, there are also some

downsides. To be able to apply this methodology,

there is a need for a textual description, about the

organization that is being studied and the

surrounding environment, as input for the

identification process. This text is written in natural

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

536

language, by someone who has some insight about

the tasks performed by the organization, which can

lead to misunderstandings due to the lack of

expressivity.

One also has to consider that the models produced

by DEMO just contemplate the Ontological aspects

performed by employees. This way, actions which

are categorized as Infological or Datalogical are not

directly included in these models. So, in order to

have a complete overview of the actions performed

by an actor, one has to consider those three kinds of

abilities. This case study revealed that in some

situations it would be useful to model the most

relevant infological and datalogical transactions.

An important lesson that we managed to prove is

that different people have different notions of what

is performed by one another. This is well showed

considering the different textual descriptions and,

consequently, the different services we obtained

from the HR and Marketing’s points-of-view. This

difference represents the gap between the customers’

expectations and the service provider’s perception of

those expectations. This gap was first identified two

decades ago (Parasuraman, Zeithaml, & Berry,

1985) and the fact that, nowadays, it still occurs in

companies proves the importance of the service

identification process. Companies still struggle to

identify and manage their services and this kind of

problems is motivating a new field of research:

Service Science.

8 CONCLUSIONS

In this paper we have stressed the problems related

with the service identification using DEMO, namely

the issues that the text description can raise. We

have concluded that the textual description of the

organization is a critical step in the service

identification process. Having it wrong may lead to

gaps between the customers’ expectations and the

provider’s perceptions of those expectations, such as

in the studied organization.

As future work we intend to overcome the

problems related to the text description. We will

evaluate the possibility of using graphical

representation of business processes, such as BPMN

models, as input for the DEMO analyses and

synthesis.

REFERENCES

CMMI for Services, version 1.3. (2010). SEI - Carnegie

Mellon University.

Albani, A., Terlouw, L., Hardjosumarto, G., & Dietz, J.

(2009). Enterprise Ontology Based Service Deﬁnition.

Amsterdam, The Netherlands: 4th International

Workshop on Value Modeling and Business

Ontologies.

Arsanjani, A. (2008). SOMA: a method for developing

service-oriented solutions (Vol. 47). IBM Systems

Jornal.

Bon, J. (2007). Foundations of IT service management

based on ITIL v3. Van Haren Publishing.

Chesbrough, J., & Spohrer, H. (2006). A research

manifesto for service science (Vol. 49).

Communications of the ACM, ACM.

Dietz, J. (2006). Enterprise ontology - theory and

methodology. Springer.

Erradi, A., Anand, S., & Kulkarni, N. (2006). SOAF: an

architectural framework for service definition and

realization. IEEE International Conference on

Services Computing.

Fan-Chao, M., Den-Chen, Z., & Xiao-Fei, X. (2005).

Business Component Identification of Enterprise

Information System. IEEE International Conference on

e-Business Engineering.

Hubbers, J., Ligthart, A., & Terlouw, L. (2007). Ten ways

to identify services (Vol. 8). The SOA Magazine.

Hubbert, E., & O'Donnell, G. (2009). Service catalog:

your prerequisite for effective IT service management

(Forrester ed.). Infrastructure & Operations

Professional, Forrester.

Huysmans, P., Ven, K., & Verelst, J. (2010). Using the

DEMO methodology for modeling open source

software development processes (Vol. 52).

Information and Software Technology, Elsevier.

Jones, S. (2005). Toward an acceptable definition of

service (Vol. 22). Journal IEEE Software.

Moody, G., & Shanks, D. (2003). Improving the quality of

data models (Vol. 28). Information Systems, Elsevier.

O´Loughlin, M. (2009). The Service Catalog - A

Practitioner Guide. Van Haren Publishing.

O'Sullivan, J. (2006). Towards a precise understanding of

service properties. Queensland University of

Technology.

Parasuraman, A., Zeithaml, V., & Berry, L. (1985). A

conceptual model of service quality and its implication

for future research (Vol. 49). Journal of Marketing.

Peffers, K., Tuunanen, T., Rothenberger, M. A., &

Chatterjee, S. (2008). A Design Science Research

Methodology for Information Systems Research (Vol.

24). Journal of Management Information Systems.

Terlouw, L., & Dietz, J. (2010). A framework for

clarifying service-oriented notions (Vol. 5). Enterprise

Modeling and Information Systems Architecture,

German Informatics Society.

Wang, Z., Xu, X., & Zhan, D. (2005). A survey of business

component identification methods and related

techniques (Vol. 2). International Journal of

Information Technology.

Zeithaml, V. A., & Bitner, M. (1996). Service Marketing.

New York: McGraw-Hill.

COMPARING SERVICES USING DEMO

537