Ontology for SEAM Service Models

Gorica Tapandjieva and Alain Wegmann

School of Computer and Communications Sciences (IC),

Ecole Polytechnique F

erale de Lausanne (EPFL),

Keywords:

SEAM, Service Modeling, Ontology, Meta-model, Alloy, Formalization.

Abstract:

A service system is a popular concept in academia and industry. At the same time, it is a challenging concept

to represent, due to its recursive nature and difﬁculty to relate it to entities in reality. In this paper we present an

ontology for modeling service systems with the SEAM systemic method. As part of the ontology, we provide

a meta-model, well-formedness rules and formalization in the Alloy language. The ontology we propose

represents an updated and minimalistic version of the existing SEAM modeling language ontology that puts

an emphasis on the behavior. We validated the ontology by modeling around 20 case studies. The running

example we use throughout this paper is one of these case studies.

1 INTRODUCTION

Services are a powerful abstraction of the value ex-

change and value creation within and across systems.

The ﬁrst foundational premise of S-D logic states

that a “service is the fundamental basis of exchange”

(Vargo and Lusch, 2008). Hence, the interaction be-

tween a company (service provider) and a customer

(service consumer) is conceptualized as a service ex-

change. But also within a company there exist ex-

changes of services between an internal service pro-

vider and an internal consumer.

The entities that exchange services are known as

service systems and they are deﬁned as “a value-

coproduction conﬁguration of people, technology, ot-

her internal and external service systems, and shared

information (such as language, processes, metrics,

prices, policies, and laws)” (Spohrer et al., 2007) (ita-

lics added). This deﬁnition reveals the recursive na-

ture of service systems, meaning that service systems

are part of both the internal structure and the external

environment of one service system.

In this paper, we explore what deﬁnes the structure

of service systems. We do that through a reﬂection on

how people conceptualize service systems. Such a re-

ﬂection implies working on an ontology. We work

on the ontology of a speciﬁc service modeling met-

hod called SEAM (Wegmann, 2003; Wegmann et al.,

2008). The ontology we develop represents a gene-

ric, scalable, but yet rigorous basis for the SEAM mo-

deling language.

In the remaining of the paper, in Section 2 we

present the context and motivation of our work.

In Section 3 we present the related work and in

Section 4, we present the service modeling with

SEAM trough an example. The research method we

follow is described in Section 5. In Section 6, we

formalize the constructs used to build SEAM service

models. Finally, we conclude in Section 7.

2 CONTEXT AND MOTIVATION

The inspiration for our work came from our collabo-

ration with our university’s IT department, where we

were involved in modeling existing and new services.

Trough modeling real services in real projects we no-

ticed that service systems often do not relate to a pre-

deﬁned entity in the reality, such as department or or-

ganizational unit. For example, what is the service

system that embodies an unofﬁcial collaboration be-

tween two departments that provide services? What

if the collaboration is between two different compa-

nies? When the collaboration becomes ofﬁcial, how

will the service system be called? This brought us to

the research question:

RQ: What deﬁnes a service system?

(Pidd, 2003) explains that “a model is an external

and explicit representation of a part of reality as seen

by the people who wish to use that model to under-

stand, change, manage, and control that part of rea-

lity”. Before doing the model, people ﬁrst concep-

290

Tapandjieva, G. and Wegmann, A.

Ontology for SEAM Service Models.

DOI: 10.5220/0006711502900298

In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 290-298

ISBN: 978-989-758-298-1

tualize the reality they perceive. A conceptualization

is formed of all objects, concepts, entities and relati-

onships among them that are assumed to exist in the

reality perceived. (Gruber, 1995, p. 908) deﬁnes on-

tology as “an explicit speciﬁcation of a shared con-

ceptualization”. More concretely, the ontology is “a

set of representational primitives with which to model

a domain of knowledge or discourse” (Gruber, 2009),

so a modeling language conforms to an ontology.

The modeling language we use is called SEAM

(Wegmann, 2003)

. Being developed in our labora-

tory (LAMS, nd) and a result of over 15 years of re-

search, SEAM has always been our ﬁrst choice for

modeling service systems. As suggested by S-D lo-

gic and service science, SEAM (1) considers services

as the fundamental basis of exchange and (2) models

the observed reality as a recursive hierarchy of service

systems. As system thinkers, when using SEAM, the

entities we choose to perceive are systems, where a

service is the behavior of a system, observed from the

system’s environment, that brings value to another sy-

stem in the same environment. We ﬁnd all perceived

systems to be service systems, so we use these two

terms interchangeably.

We seek an answer to our research question by de-

signing a minimalistic ontology of the SEAM service

modeling language. In this process we found that in

service systems the emphasis is on the behavior. The

contribution of our ontology is that service modelers

are encouraged to consider the system structure as

being emergent from the perceived or desired beha-

vior of the service system. Note that our goal was not

to develop a universal ontology of what exists, but to

develop an ontology that can be used to design and

describe services in a model.

3 RELATED WORK

Many different perspectives can be adopted for the

management of services (Bardhan et al., 2010). A

service modeling language is adapted not only to the

perspective, but to the motivation and the needs for

representing the information around services. In this

section we give an overview of the modeling langua-

ges in two of the ﬁve proposed perspectives by (Bard-

han et al., 2010): computer science and marketing.

Computer Science Perspective

The computer science perspective of services is wi-

dely known as service-oriented architecture (SOA)

SEAM is a family of methods used for consulting and

teaching strategic thinking, business/IT alignment, and re-

quirements engineering.

and mostly applies to the usage of software soluti-

ons to facilitate the interaction of value co-creation

between providers and consumers. SOA research and

application focuses on technical architecture that or-

chestrates software services, such as WS-* web ser-

vices, APIs and RESTful services, in heterogeneous

and distributed environments. As a service appro-

ach, SOA tries to separate the concern between the

service description and implementation (Arsanjani,

2004). In an SOA context, services are loosely cou-

pled, platform-independent, abstract the implementa-

tion and enable interoperability among systems.

Service Oriented Architecture Modeling Lan-

guage (SoaML) (SoaML v1.0.1, 2012) is speciﬁ-

cation project from the Object Management Group

(OMG) (OMG, na) that provides a standard way to

design, architect and model services within an SOA.

The SoaML speciﬁcation describes (1) a metamodel

and (2) a set of extensions to the basic UML model

elements, called a UML proﬁle.

The Service Modeling Language (SML) (Popescu

et al., 2009) and the Web Service Description Lan-

guage (WSDL) (Christensen et al., 2001), are XML

based modeling languages. The XML ﬁles descri-

bing the service contain information about the service

conﬁguration, deployment, monitoring, etc. XML is

not graphical, so it is not used in people’s commu-

nication, but it is suitable for task automation, im-

plementing interoperability, communication and ex-

change between applications, etc. The Uniﬁed Ser-

vice Description Language (USDL) (Cardoso et al.,

2010) is also based on XML that aims at unifying the

technical and the business perspectives of a given ser-

vice. The Web Services Business Process Execution

Language (WS-BPEL, only BPEL for short) (Rosen

et al., 2008) is another XML-based language used to

deﬁne the coordination and integration of Web Servi-

ces within higher-level business processes of a com-

pany. BPEL is platform independent and provides in-

dependence and ﬂexibility by allowing the separation

of the business process interaction from the web ser-

vices (Rosen et al., 2008).

The visual representation of the company’s pro-

cesses that are exposed as business services is done

with Business Process Modeling Notation (BPMN)

diagrams (Rosen et al., 2008). BPMN has a nota-

tion that is understandable by business analysts, ma-

nagers and technical developers. There is a possibility

to compile BPMN diagrams into executable BPEL,

and (White, 2005) has demonstrated how. This ma-

kes BPMN and BPEL the bridge between the compu-

ter science and marketing/management perspectives.

Enterprise Architecture (EA) is another discipline

where services are modeled. ArchiMate

is a wi-

Ontology for SEAM Service Models

291

dely adopted EA modeling language that aids the

technology-integration efforts by creating models that

within and between different domains. ArchiMate ex-

presses service-orientation with the so-called service

layers and service implementation layers that realize

the services. Services from a higher layer are lin-

ked with and typically use services from the lower

layers. ArchiMate identiﬁes three main layers: bu-

siness, application and technology (Lankhorst, 2009),

but the most recent speciﬁcation includes a strategy

and a physical layer (Josey et al., 2016).

Marketing Perspective

Even before the introduction of SOA, services existed

in the marketing discipline (Hill, 1977) with the focus

on the service consumers, such as customers, users

and clients. We ﬁnd that the marketing perspective of

services always takes into consideration the value that

might arise from using information systems (IS) and

IT in the service customization, and uses modeling

languages that express service offerings, without sho-

wing the technical implementation.

The e3service is an approach for generating ser-

vice bundles, by using the notion of functional con-

sequence to match the customer perspective and the

supplier perspective (Razo-Zapata et al., 2015). The

approach includes an ontology of constructs for ser-

vice marketing and belongs to the e3family of ontolo-

gies for building service networks (Razo-Zapata et al.,

2012).

The service blueprint (Shostack, 1984) is a ﬂow-

chart of all interactions belonging to the service deli-

very. It represents a precise deﬁnition allowing to ex-

plicitly depict roles of consumers, service providers,

and supporting services.

Business models are used for the analysis and de-

sign of the business logic of a company (Osterwalder,

2004). There are several service approaches that have

been inspired by the widely cited and broadly app-

lied Business Model Canvas (BMC) (Osterwalder and

Pigneur, 2010). The Service Logic Business Model

Canvas (SLBMC) (Ojasalo and Ojasalo, 2015) inclu-

des the original nine blocks from the BMC and consi-

ders a provider viewpoint (“From our point of view”)

and a customer viewpoint (“From customer point of

view”) in each of the blocks. Another approach is the

Service Business Model Canvas (SBMC) (Zolnowski

et al., 2014) that modiﬁes the BMC to represent co-

creation in the model. Finally, there is another can-

vas visualization approach, the Service Model Canvas

(SMC) (Turner, 2015a; Turner, 2015b), designed by a

user-experience professional.

SEAM is a modeling method, with its own lan-

guage, that is used for services modeling. It enables

modelers to explicitly show different viewpoints of

an organization. It embeds modeling principles, heu-

ristics and constructs for representing and analyzing

different abstraction levels of systems and behavior.

SEAM can be used both in the computer science and

in the marketing perspective. In the next section we

present details of the SEAM modeling technique on a

concrete example.

4 SEAM SERVICE MODELING

In a nutshell, SEAM represents an organization as a

hierarchy of systems (from business down to IT) that

provide services, where a system refers to entities in

the reality perceived: a department, an employee, an

IT system, or an application (Wegmann et al., 2008).

In the mentioned hierarchy, a system can have two

views: abstract and concrete. To show the abstract

view, a system is modeled as a whole, in which the sy-

stems components are ignored and the focus is on the

behavior provided as a service. In the concrete view,

a system is modeled as a composite in which other sy-

stems as a whole are displayed with the relationships

among these systems’ services. A brief overview of

the SEAM modeling constructs used in this paper is

presented in Table 1.

In the next part, we present the Infoscience ex-

ample where we apply SEAM concepts for creating a

two-level service model. The purpose of this model

is to illustrate the SEAM modeling process on a real

scenario. Note that to keep the model simple, we omit

many details.

Example: A University’s Infoscience Tool

Imagine reading a university’s annual report in which

there is a section about the research performance in

terms of scientiﬁc publications. How does the univer-

sity’s management measure such performance? The

answer lies in Infoscience, a tool that enables the ma-

nagement and access to scientiﬁc outputs. This tool is

the result of a partnership between the librarians and

the IT department. The main users of Infoscience are

the university’s researchers, who use it in the process

of archiving their scientiﬁc production, organizing it,

and afterwards, if needed, reclaiming the content. Be-

sides researchers, Infoscience is used by the univer-

sity’s management and deans ofﬁces in the analysis

of publications and citations.

In SEAM, such a scenario is conceptualized as

following. Every actor in the case description cor-

responds to a service system. We do not know the

details of the partnership around Infoscience, so it is

a black box (system as a whole), that we name Infos-

cience value network. In this case, the name is the

choice of the modeler because no such department or

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

292

organization (Infoscience value network) exists. The

behavior of this partnership is the service that we call

Manage and facilitate access to scientiﬁc outputs. Si-

milarly, we conceptualize University’s direction and

deans ofﬁces, existing entities, as a black box, with

the behavior Measure the university’s research per-

formance. These two systems combine their behavior

in a the process we conceptualize as Perform publica-

tions and citations analysis. They are also the com-

ponents of the composite system (the white box) that

we name Value network of open access scientiﬁc li-

terature at a university. Again, this value network is

not recognized as an ofﬁcial entity. This is depicted

on the right-hand side in Figure 1.

We further reﬁne the Infoscience value network to

include other service systems that contribute to the

implementation of Manage and facilitate access to

scientiﬁc outputs.

• A steering committee consists of high level sta-

keholders and experts like the dean of research,

the head of the library, the head of an IT unit, the

IT systems coordinator, etc. This committee is re-

sponsible for making strategic decisions.

Table 1: SEAM Modeling language visual vocabulary.

System

System – an entity in the perceived

reality, such as a company, a depart-

ment, an organization. A system

has two views, whole, marked with

‘[w]’, and composite, marked with

‘[c]’.

System behavior (Wegmann et al., 2008)

Service – the behavior of a system as

a whole representing a service offe-

red by a system.

Process – the behavior of a system

as a composite deﬁning a service

implementation.

Links

Use (invoke) link between services

and processes, in a system as a com-

posite. This link means that the pro-

cess uses (invokes) the connected

services.

Reﬁnement (decomposition) link,

connecting the abstract and concrete

view of a system, [w] and [c] re-

spectively. The services from the

system as a whole have correspon-

ding processes in the system as a

composite. These processes show

the implementation of services.

• Representative librarians for the university

sections and faculties, responsible for providing

support to researchers.

• The Infoscience technical coordinator, responsi-

ble for the day to day operations, third level user

support and development of new features.

• The Infoscience developer, responsible for the

web development and implementation of new In-

foscience features.

• The Infoscience web application, serving as a

web interface to the digital document repository.

• A bundle of IT infrastructure resources and pe-

ople providing the execution environment for the

Infoscience application.

In the second level we show this Infoscience va-

lue network system as a composite with the process

that implements the mentioned Manage and facilitate

access to scientiﬁc resources. This process uses all

the services from all of the composing systems seen as

a whole that are part of the Infoscience value network

system. There is one person, the Developer, and one

application, the Infoscience web application, among

these systems. In Figure 1 on the left, we illustrate the

SEAM service model showing the interactions and

the service exchange between the systems collabora-

ting in the implementation of the Manage and facili-

tate access to scientiﬁc outputs.

In a service-oriented environment, there is no de-

ﬁnite number of levels between two systems. We can

systematically continue the modeling in the lower le-

vels. For example, the Infoscience IT infrastructure

system can be expanded to show the service imple-

mentation and the composing systems, most of them

IT systems. In some modeling approaches, like Ar-

chiMate (Josey et al., 2016), there is only one appli-

cation layer where all applications must be modeled,

so our example with IT systems at the second (Infos-

cience value network) and third level (Infoscience IT

infrastructure) would not be supported. As a conse-

quence, we need a meta-model that allows for scala-

bility in terms of levels. Hence, a taxonomy for the

levels is not present in SEAM service models, so mo-

delers are free to embed a taxonomy in their diagrams

and say that there is an end user level and several ap-

plication levels.

5 RESEARCH METHOD

The research method we used in the development of

the SEAM service modeling ontology conforms to the

design science in information systems research fra-

mework and guidelines proposed by (Hevner et al.,

Ontology for SEAM Service Models

293

Figure 1: SEAM model with two organizational levels for the Infoscience project.

2004). Next, we elaborate how we fulﬁlled the re-

commendations in each guideline.

Guideline 1: Design as an Artifact

Our research resulted with an artifact, the SEAM ser-

vice modeling ontology. It is an updated, ﬂexible, ab-

stract, but yet easy to use in constructing service mo-

dels. The ontology releases the existing constraint of

not having a cycle between hierarchical levels and it

emphasizes the behavior in service models.

Guideline 2: Problem Relevance

The business needs we address with our research

come from people that belong to two broad catego-

ries: academics and practitioners.

• Academics – The simpliﬁed SEAM service mo-

deling ontology helps LAMS researchers to apply

the SEAM method with ease in projects that span

across multiple domains. It also helps them to de-

ﬁne the service system as an existing one or as

a collaboration between actors that strive towards

the same behavior.

• Practitioners – Our research is based on a colla-

boration with practitioners from our university’s

IT department. They care about how services are

provided to the external customers and which en-

tities are involved in the service implementation.

SEAM service models facilitate the discussions

through the focus on the behavior of the system.

Guideline 3: Design Evaluation

We used two techniques:

1. Case studies: Through the course of our research,

we have interviewed and collected information on

around 20 case studies. Each of the cases involved

solving a different problem that included service

systems where our ontology was used in concep-

tualizing and modeling the problem situation and

solution. In Section 4 we show only one of them.

2. Formal model simulation: We formalized our on-

tology in a ﬁrst-order logic language (Alloy) and

simulated it with the Alloy analyzer to analyze

and derive modeling rules.

Guideline 4: Research Contributions

The main contribution of our ontology is the shift

from focusing on systems structure towards focusing

on the system behavior while modeling in SEAM. In

the knowledge base, service science and SEAM be-

neﬁt from a simplistic ontology applicable in all or-

ganizational levels. Both domains beneﬁt from the

reﬂection about the behavior of service systems.

Guideline 5: Research Rigor

Our ontology is based on and conforms to the SEAM

systemic paradigm (Wegmann, 2003). Consequently,

we applied theories and concepts coming from sys-

tems thinking and service science. To be able to de-

sign and evaluate the ontology artifact, we used meta-

modeling and the Alloy constraint solver tool.

Guideline 6: Design as a Search Process

Our search for an effective artifact had a main con-

straint of being capable to create “standard” SEAM

models. To have such an artifact, we were building

and evaluating our meta-model with the LAMS rese-

archers and we included modeling rules coming from

the previous developments of SEAM.

Guideline 7: Communication of Research

The initial ontology has been communicated to the

academic community via a publication and a poster

presentation at a conference, (Tapandjieva and Weg-

mann, 2014), as a meta-model for automatic model

generation. Technology-oriented audiences, namely

IS architects, have read informal documentation and

description of the artifact. We have not communica-

ted the artifact to the management-oriented audiences

in the form in which it is presented in this paper. Ac-

cording to our understanding, management-oriented

audiences beneﬁt from the visual model that repre-

sents an abstraction of their universe of discourse, so

they do not need an additional abstraction in the form

of an ontology or meta-model.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

294

hasBehavior_w 1..*

System

uses 1..*

implementedBy 0..1

Service

Process

hasBehavior_c 1..*

1 isBehaviorOf_w

isBehaviorOf_c

implements 1

usedBy 1..*

Figure 2: Meta-model of SEAM service modeling concepts

used in this paper.

6 ARTIFACT: AN ONTOLOGY

FOR SEAM SERVICE MODELS

In this section, we present our artifact, the SEAM

modeling language ontology, in a more formal way.

We ﬁrst present the meta-model with the constructs

that comprise the ontology for SEAM service models

(Subsection 6.1). Then, we list the well-formedness

rules that are not captured in the meta-model (Sub-

section 6.2). Afterwards, we formalize both the meta-

model and the rules in a declarative language called

Alloy (Jackson, 2002) (Subsection 6.3) with which

we verify the correctness of the meta-model and the

modeling rules.

6.1 SEAM Meta-model

Since 2008, researchers have been developing meta-

models

that cover a bigger set of SEAM mo-

deling constructs (Rychkova, 2008; L

e and Weg-

mann, 2013). In this paper we use SEAM models that

focus on collaboration among services from different

systems, namely people, IT systems, organizations,

companies. Our interest is the value creation through

such collaboration, from which new services emerge.

Then, we study the surrounding context (upper level)

where the new service is used, again in collaboration

with other systems. And then again, understand the

upper context, until we have interest in doing so. The

example in Section 4 illustrates how we model col-

laborations with SEAM. In this paper we do not use

all concepts deﬁned in the existing meta-models, but

we use only systems (whole and composite), beha-

vior (service and process) and connections (decompo-

sition and usage). We have built an ontology with the

entities: System, Service and Process. Our proposed

meta-model for this ontology is depicted in Figure 2.

Every relationship between entities has a symmetric

In this paper we use the term meta-model and informa-

tion model interchangeably.

pair. We consider the cardinality of the starting entity

to be always one. For example, the hasBehaviorOf w

one-to-many relationship between System – Service

means that a system perceived as a whole can have

one or more services, and the one-to-one isBehavi-

orOf w relationship between Service – System means

that one service can belong to only one system.

The concept of a system as a whole is captured

in the hasBehaviorOf w relationship, with services

being the behavior of systems as a whole. Similarly

the hasBehaviorOf c means that the behavior of sys-

tems as a composite are processes.

The two kinds of links from Table 1 are captu-

red in the relationships between Process – Service.

The implementedBy and implements stands for the

reﬁnement and implementation concept. The usage

(invoke) link is captured with the uses relationship,

telling that a process can use multiple services. The

usedBy relationship means that the same service can

collaborate in different processes.

In the meta-model, we omit entities for the con-

cepts of a system as a whole and system as a compo-

site. As mentioned before, these concepts are repre-

sented with the relationships behaviorOf

w and beha-

viorOf c. We also do not include a System – System

relationship to denote that a system as a composite

contains processes and systems as a whole. In short,

the systems as a whole that belong to the system as a

composite must participate with their services in the

process; they are not free-ﬂoating in the composite.

Consequently, the following query System – behavi-

orOf c – Process – uses – Service – behaviorOf w

– System gives all systems as a whole belonging to

the starting system as a composite. Additional details

are presented in the next Subsection 6.2, with the mo-

deling rules.

From a systems thinking perspective, the dis-

tinction between the concepts of a system as a whole

and a composite is based in epistemology; these con-

cepts depend on the observer’s (the modeler’s) know-

ledge and relation to the reality while describing the

systems. It is the observer who decides the viewpoint

he takes when modeling the reality: the context that

he knows (system as a composite) where many sys-

tems as a whole interact (services connected to a pro-

cess). In addition, for newly created services, often

based on collaboration, there is no formal entity that

hosts the process execution. In such cases, the ob-

server derives the system name from the process (be-

havior). To conclude, we have two reasons for omit-

ting the concepts of a whole and a composite from

the meta-model, the ﬁrst one being pragmatic (they

can be computed), and the second philosophical.

Ontology for SEAM Service Models

295

6.2 Well-formedness Rules

The well-formedness rules of a modeling language

complement the meta-model to ensure the consis-

tency of models. They are also created to avoid the

semantic ambiguities that might arise in the instances

of the meta-model. We summarize the SEAM well-

formedness rules in the following list:

R1. A service is unique to one system as a whole, so

no two systems have one same service.

R2. A process is unique to one system as a compo-

site, so no two systems have one same process.

R3. A process can implement only one service.

R4. A process must be connected to at least one ser-

vice. Otherwise, there is no relationship among

systems as a whole, and the overall observation

of the system as a composite is put in question.

R5. The decomposition relationship, shows the reﬁ-

nement from the abstract view of a system (the

whole) to the concrete view of a system (the

composite). The service present in the whole,

becomes a process in the composite view. As a

consequence, the process, and the service it im-

plements, must belong to the same system, so a

process cannot implement a service from another

system as a whole, different from the process’

system as a composite.

R6. Recursion between levels is allowed. A process

can be connected with the service it implements.

Such recursion does not have to be immediate,

it can happen at any level in the organizational

hierarchy.

6.3 Formalization in Alloy

We use Alloy to formalize the SEAM meta-model

concepts and the well-formedness rules. Then, we

use the Alloy Analyzer to generate instance models

or counter-examples in a domain we have speciﬁed.

Getting meaningful instances would indicate that our

formalization is consistent in the domain we have set.

Alloy (Alloy, nd; Jackson, 2002) is a declarative

structural modeling language based on ﬁrst-order lo-

gic. It comes with a constraint solver, the Alloy Ana-

lyzer, that automatically ﬁnds models that satisfy the

formulas written with the Alloy language. The Alloy

code usually describes basic structures, called signa-

tures, and has detailed constraints applied to the struc-

tures. Constraints are expressed in terms of facts, pre-

dicates, assertions or quantiﬁers.

The following code shows the complete forma-

lization of the SEAM meta-model and the well-

formedness rules. There is a signature (sig keyword)

for each concept from the meta-model: System, Ser-

vice and Process. The cardinalities are coded with the

corresponding keywords: 1..* is mapped to some, 0..1

is mapped to lone and 1 is mapped to one.

sig S ys te m {

ha s B e ha vi or _ w : some Se rvi ce ,

ha s B e ha vi or _ c : set P r o c es s

}

sig S er vi ce {

is B e h av io rO f _w : one S yst em ,

im p l e me nt ed B y : lone Pr oce ss ,

us ed By : set P r o ce ss

}

sig P ro ce ss {

is B e h av io rO f _c : one S yst em ,

im pl e m e n t s : one Se rvi ce , //R3

us es : some S er vi ce //R4

}

fact un i qu eS e rv ic e I n Sy s t e m { //R1

no s e r : Se rv i ce , s1 : Sy ste m , s2 : Sy st e m |

ser in s 1 . ha sB e h a vi or _w and

ser in s 2 . ha sB e h a vi or _w and s1 !=s 2

}

fact un i qu eP r oc es s I n Sy s t e m { //R2

no p : P roc ess , s 1 : S yst e m , s2 : Sy st em |

p in s1 . h a sB eh av i o r _c and

p in s2 . h a sB eh av i o r _c and s 1 !=s2

}

fact r e f i ne me nt { //R5

all s : S erv ice , p : Pr o ce ss | p . i m p le me nt s=s =>

s . is B e h av io rO f _ w=p. i sB e h a vi or Of _ c and

s . im p l e me nt ed By=p

all p : P roc ess , s : Se r vi ce | s . i mp le me n t e dB y=p =>

s . is B e h av io rO f _ w=p. i sB e h a vi or Of _ c and

p . im pl em e n t s=s

}

fact s ym me tr y {

all s : S erv ice , p : Pr o ce ss | s in p . us es => p in s . u se d By

all s : S erv ice , p : Pr o ce ss |

p . im pl em e n t s=s<=> s. im pl em en t e d By=p

all s ys : Sy ste m , s e r : Ser vi ce |

ser . is Be h av io rO f _ w = s ys <=> ser in s y s . h as Be h a v io r_ w

all s ys : Sy ste m , p : P r oc es s |

p . is B e h av io rO f _ c = s ys <=> p in sy s . ha s B e ha vi or _ c

}

run {} fo r exactly 4 S er v ic e , exactly 2 Pr o ce s s ,

exactly 3 S ys te m

Listing 1: Meta-model formalization in Alloy.

The well-formedness rules R3 and R4 are already

captured with the cardinalities. The remaining rules

are written as facts. We ﬁnally specify the domain

for which we want the Alloy Analyzer to generate an

instance model (the run command).

Having an instance means that the Alloy code is

correct and not over-constrained for the domain we

have set. The instance in Figure 3 is one of the

many that satisﬁes the constraints written for the well-

formedness rules for the domain exactly 4 Service, ex-

actly 2 Process, exactly 3 System. Note the immedi-

ate cycle that exists between Service3 and Process0.

Such cycles are allowed to capture situations found in

reality. We demonstrate this with an example.

Imagine the hosting service offered by a data cen-

ter. Such a service is implemented by using a server

room, racks, power supply and other technical resour-

ces. In addition, the data center uses a web site to

display information about the status of the resources,

for monitoring purposes. This website is hosted on a

machine in the data center.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

296

Figure 3: One Alloy-generated instance where all well-

formedness rules are respected.

6.4 Evaluation

The Alloy checking is a formal evaluation of the on-

tology. It proves that correct SEAM models can be

generated with our meta-model. Around 20 case stu-

dies that we modeled with our ontology during our

collaboration with the IT department is another form

of evaluation. The difﬁculties we encountered with

the case studies in conceptualizing systems were ea-

sily overcome by focusing on the behavior, i.e. the

process and the emerging service. In addition, one

practitioner from the IT department used our meta-

model and developed tools upon it. We still plan to

conduct additional evaluation in the form of user stu-

dies, interviews with more practitioners and survey.

6.5 Limitations

Several other aspects of SEAM are not presented and

discussed in this paper. One is the functional hierar-

chy, more precisely the decomposition of the behavior

into sub-services and sub-processes. In addition, the

meta-model does not capture temporal and sequential

elements, like change of state over time or after an

action. This can be done by enriching the meta-model

with entities that show properties of systems, services

and processes. Previous SEAM meta-models inclu-

ded these concepts (L

e and Wegmann, 2013).

7 CONCLUSION

SEAM modeling focuses not only to the user percep-

tion of the value that the service brings, but it also

gives details on the perception of the systems in the

multiple organizational levels of the service provider.

The service exchange and value co-creation among

systems are present across the whole organization, not

only at the end-user level. Every system, namely or-

ganization, person, IT application, provides a service,

so with the proposed ontology we leverage on the ge-

neral SEAM contribution of services being explicitly

modeled at any organizational level of interest. Such

conceptualization uses the ﬁrst foundational premise

of service-dominant logic: “service is the fundamen-

tal basis of exchange” (Vargo and Lusch, 2008).

SEAM had already been used in such contexts, but

it provides a set of models and tools, that combined

are difﬁcult to use in a large scale projects. Their ex-

isting meta-models encompass entirely SEAM. In this

paper we suggested to use a stripped down version of

SEAM. For this version we propose an ontology that

offers a new perspective, the focus on the behavior

of the system, not the system itself. All the relations-

hips among the Service and the Process concept in the

meta-model shift the modeling focus around the beha-

vior, i.e. what systems do together. In such a version,

cycles are allowed and even external actors, such as

regulators and suppliers, are considered in a service

implementation.

Service science literature discusses mainly one le-

vel of value co-creation, the one with the customer or

end user. Here, we propose to reuse the same princi-

ple inside an organization, by only focusing on what

systems do together. With our ontology we do not in-

troduce a classiﬁcation of service providers and con-

sumers. We focus on the interaction, collaboration

and co-creation among systems, regardless of their

position in the organizational hierarchy, or in the com-

pany. The analysis of the dynamics between a ser-

vice provider and consumer are systematically appli-

cable on the systems in the service provider, inter-

nally, across the whole organization.

During the course of our research, we have reali-

zed that the existence of systems (we choose to ob-

serve) is strongly dependent on our perception of the

behavior of these systems, i.e. services. In SEAM,

processes show collaboration and value co-creation,

so when we try do deﬁne the system with its bounda-

ries where this collaboration happens, the choice for

the system name (1) expresses the function of the col-

laboration, or (2) relates to an organization, depart-

ment, or an entity from the observed reality. Overall,

systems thinking is an epistemology (Mingers, 2006,

p. 87). The concepts of a system as a whole and a sy-

stems as a composite only describe how we choose to

perceive the reality, so they are not strictly represen-

ted in the meta-model of the ontology.

Ontology for SEAM Service Models

297

REFERENCES

Alloy (n.d.). Alloy: a language & tool for relational models.

http://alloy.mit.edu/.

Arsanjani, A. (2004). Service-oriented modeling and

architecture. https://www.ibm.com/developerworks/

library/ws-soa-design1/.

Bardhan, I. R., Demirkan, H., Kannan, P. K., Kauffman,

R. J., and Sougstad, R. (2010). An Interdisciplinary

Perspective on IT Services Management and Service

Science. Journal of Management Information Sys-

tems, 26(4):13–64.

Cardoso, J., Barros, A., May, N., and Kylau, U. (2010). To-

wards a uniﬁed service description language for the

internet of services: Requirements and ﬁrst develop-

ments. In Services Computing (SCC), 2010 IEEE In-

ternational Conference on, pages 602–609. IEEE.

Christensen, E., Curbera, F., Meredith, G., Weerawarana,

S., et al. (2001). Web services description language

(wsdl) 1.1.

Gruber, T. (2009). Ontology. http://tomgruber.org/writing/

ontology-deﬁnition-2007.htm.

Gruber, T. R. (1995). Toward principles for the design of

ontologies used for knowledge sharing? International

journal of human-computer studies, 43(5-6):907–928.

Hevner, A., March, S., Park, J., and Ram, S. (2004). Design

science in information systems research. MIS quar-

terly, 28(1):75–105.

Hill, T. P. (1977). On goods and services. Review of income

and wealth, 23(4):315–338.

Jackson, D. (2002). Alloy: A lightweight object modelling

notation. ACM Transactions on Software Engineering

and Methodology (TOSEM), 11(2):256–290.

Josey, A., Lankhorst, M., Band, I., Jonkers, H., and Quartel,

D. (2016). An introduction to the ArchiMate

 3.0

speciﬁcation. White Paper from The Open Group.

LAMS (n.d.). Systemic modeling laboratory – LAMS,

EPFL. http://lams.epﬂ.ch/.

Lankhorst, M. (2009). Enterprise Architecture at Work:

Modelling, Communication and Analysis. Springer.

e, L.-S. and Wegmann, A. (2013). Hierarchy-oriented

modeling of enterprise architecture using reference-

model of open distributed processing. Computer Stan-

dards & Interfaces, 35(3):277–293.

Mingers, J. (2006). Realising systems thinking: knowledge

and action in management science. Springer Science

& Business Media.

Ojasalo, K. and Ojasalo, J. (2015). Adapting business

model thinking to service logic: an empirical study

on developing a service design tool. THE NORDIC

SCHOOL, 309.

OMG (n.a.). About OMG. http://www.omg.org/about/.

Osterwalder, A. (2004). The business model ontology: A

proposition in a design science approach. PhD thesis,

L’Ecole des HEC de l’Universit

e de Lausanne.

Osterwalder, A. and Pigneur, Y. (2010). Business model ge-

neration: a handbook for visionaries, game changers,

and challengers. John Wiley & Sons.

Pidd, M. (2003). Tools for Thinking: Modelling in Mana-

gement Science. Wiley, second edition edition.

Popescu, V., Pandit, B., and Smith, V. (2009). Service mo-

deling language, version 1.1, W3C recommendation.

https://www.w3.org/TR/sml/.

Razo-Zapata, I. S., De Leenheer, P., Gordijn, J., and Ak-

kermans, H. (2012). Service network approaches. In

Handbook of service description, chapter 3, pages 45–

74. Springer.

Razo-Zapata, I. S., Gordijn, J., De Leenheer, P., and Wie-

ringa, R. (2015). e3service: A critical reﬂection and

future research. Business & information systems engi-

neering, 57(1):51–59.

Rosen, M., Lublinsky, B., Smith, K. T., and Balcer, M. J.

(2008). Applied soa: Service-oriented architecture

and design strategies.

Rychkova, I. (2008). Formal semantics for reﬁnement veri-

ﬁcation of entreprise models. PhD thesis, EPFL.

Shostack, G. L. (1984). Designing services that deliver.

Harvard Business Review, (1):133–139.

SoaML v1.0.1 (2012). OMG Service Oriented Architecture

Modeling Language, Version 1.0.1. Technical report,

Object Management Group (OMG).

Spohrer, J., Maglio, P. P., Bailey, J., and Gruhl, D. (2007).

Steps toward a science of service systems. Computer,

40(1):71–77.

Tapandjieva, G. and Wegmann, A. (2014). Speciﬁcation and

implementation of a meta-model for information sys-

tems cartography. In Joint Proceedings of the CAiSE

2014 Forum and CAiSE 2014 Doctoral Consortium

co-located with the 26th International Conference on

Advanced Information Systems Engineering (CAiSE

2014), Thessaloniki, Greece, June 18-20, 2014., vo-

lume 1164, pages 113–120. CEUR-WS. org.

Turner, N. (2015a). Introducing the service model can-

vas. http://www.uxforthemasses.com/service-model-

canvas/.

Turner, N. (2015b). The updated service model

canvas. http://www.uxforthemasses.com/updated-

service-model-canvas/.

Vargo, S. L. and Lusch, R. F. (2008). Service-dominant lo-

gic: continuing the evolution. Journal of the Academy

of marketing Science, 36(1):1–10.

Wegmann, A. (2003). On the systemic enterprise architec-

ture methodology (SEAM). volume 3, pages 483–490.

Wegmann, A., Kotsalainen, A., Matthey, L., Regev, G.,

and Giannattasio, A. (2008). Augmenting the Zach-

man enterprise architecture framework with a syste-

mic conceptualization. In 12th International IEEE

Enterprise Distributed Object Computing Conference,

ECOC 2008, 15-19 September 2008, Munich, Ger-

many, pages 3–13. IEEE Computer Society.

White, S. (2005). Using BPMN to model a BPEL process.

Zolnowski, A., Weiß, C., and Bohmann, T. (2014). Repre-

senting service business models with the service busi-

ness model canvas–the case of a mobile payment ser-

vice in the retail industry. In System Sciences (HICSS),

2014 47th Hawaii International Conference on, pages

718–727. IEEE.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

298