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
Copyright
c
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 Denition.
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