I m p r o v i n g ... M o d e l A n a...

I m p r o v i n g  ... M o d e l   A n a...
Improving E-Business Design through Business
Model Analysis
Tharaka Ilayperuma
REPORT SERIES/DSV 10-009
Improving e-Business Design through
Business Model Analysis
Tharaka Ilayperuma
©Tharaka Ilayperuma, Stockholm 2010
ISSN 1101-8526
ISBN 978-91-7447-153-3
Printed in Sweden by US-AB, Stockholm 2010
Distributor: Department of Computer and Systems Sciences, Stockholm University
Dedicated to my
Loving Mother and Father
Abstract
To a rapidly increasing degree, traditional organizational structures evolve in
large parts of the world towards online business using modern Information
and Communication Technology (ICT) capabilities. For efficient applications of inter-organizational information systems, the alignment between
business and ICT is a key factor. In this context, business analysis using
business modelling can be regarded as a first step in designing economically
sustainable e-business solutions.
This thesis examines how business modeling can be used to improve
e-business design. We examine how business stakeholder intentions and
different objectives of business collaborations can be used to obtain an explorative business model that can be used as a basis for designing e-business
solutions. The thesis proposes a set of artifacts for business modeling and eservice design. In regard to business modeling, we propose methods that
consider internal aspects such as strategic intentions of actors and external
aspects such as business collaborations among them. Considering stakeholder intentions, we introduce a method to design business models based on
goal models. A set of templates for designing goal models and a set of transformation rules to obtain business models based on goal models are proposed. To further improve business models considering business collaborations, we suggest a classification of business transactions that considers underlying business objectives of business collaborations. Utilizing the suggested business transactions, we then propose a method to improve business
modeling. Finally, we propose a method for designing e-services using business models. The methods suggested support business modelers as well as
process and services designers in executing their tasks effectively. The methods have been assessed through applications in two cases.
Acknowledgements
Firstly, I would like express my gratitude to my academic supervisor Professor Paul Johannesson for his excellent supervision and the knowledge I
gained since I started my research activities at the Department of Computer
and Systems Sciences (DSV). During the past couple of years, he has been
very good in keeping us busy publishing our research activities in reputed
scientific forums. Secondly, I would like to thank Dr. Jelena Zdrakovic for
overseeing latter part of studies as my co-supervisor. I gained enormous
amount of experience by working with her lately in the last couple of years
of my PhD studies.
Secondly, I would thank the Swedish Development Cooperation Agency
(SIDA) for funding my research activities at DSV. In addition to that, I extend my appreciation to the University of Ruhuna, Sri Lanka for granting me
study leave to pursue my higher studies.
Dr. Prasad Jayaweera, of the University of Ruhuna, is appreciated for his
valuable help at the beginning to establish the link with my academic supervisor, Paul. Dr. Gihan Wickramanayake of the University of Colombo is also
acknowledged for his help at the beginning. My gratitude also goes to Dr.
P.A. Jayantha of the University of Ruhuna and Dr. Upali Mampitiya, Academic Dean of the Monash College in Sri Lanka for their great support in
encouraging me at all times.
My special thanks go to DSV/SYSLAB research group members Maria
Bergholtz, Birger Andersson, and Ananda Edirisuriya for all the knowledge I
gained through many fruitful discussions and working as a team. Also I
would like to thank all the personnel at DSV for providing a pleasant environment to do my research activities in. Special thanks go to Birgitta Olsson,
Sören Gustafsson and Fatima Ferreira at DSV for their support to solve various administrative issues in timely manner.
I also thank my colleague Rasika Dayaratne who is a PhD student at DSV
for sharing all the good and bad times together. One of my friends, Nalin
Navaratne, is also acknowledged for his support in numerous ways during
my studies. My special thanks go to Sanjeewa Pattiwila, of the Sri Lankan
Embassy in Sweden for his assistance during my study period in Sweden.
Finally, I would like to thank my parents and two sisters for their love and
support. I am also grateful to my loving wife Chandramali for releasing me
from all the housework and being so patient. I did not forget you, Visith, my
darling son, who never wanted to see me working.
Contents
1 Introduction ............................................................................................ 15 1.1 Research problems ............................................................................................. 17 1.2 Goals of the research......................................................................................... 20 1.3 Purpose of the research .................................................................................... 20 1.4 Research methodology ...................................................................................... 21 1.5 Research process ................................................................................................ 22 1.6 Publications .......................................................................................................... 25 1.6.1 Overview of related publications ............................................................ 25 1.6.2 Other Publications ..................................................................................... 29 1.7 Disposition............................................................................................................ 31 2 Background and Related Work............................................................ 33 2.1 Requirements engineering................................................................................ 33 2.2 Goal models ......................................................................................................... 36 2.3 Business models ................................................................................................. 41 2.3.1 Ontologies for business modeling .......................................................... 43 2.3.1.1 The Business Modeling Ontology (BMO) ..................................... 45 2.3.1.2 e3 value ontology .............................................................................. 50 2.3.1.3 REA ontology ..................................................................................... 52 2.4 Frameworks for modeling business collaborations ..................................... 55 2.4.1 Business collaborations and business transactions ........................... 55 2.4.2 Fundamental activities of a business transaction............................... 57 2.5 Service-oriented modeling ............................................................................... 59 2.6 Related work on business-oriented e-service design ................................. 62 2.7 Running business scenarios ............................................................................. 64 2.7.1 Massively Multiplayer Online Games (MMOG) case ........................... 64 2.7.2 Eye-care health case ................................................................................ 65 3 Analyzing Resources, Resource Transfers and Conversion
Activities ................................................................................................. 67 3.1 Introduction ......................................................................................................... 67 3.2 Resources ............................................................................................................. 68 3.3 Resource transfers ............................................................................................. 70 3.4 Conversion activities .......................................................................................... 71 3.5 Summary .............................................................................................................. 71 4 Designing Business Models Based on Goal Models ......................... 73 4.1 Introduction ......................................................................................................... 73 4.2 Relating goal and business contexts .............................................................. 74 4.3 Modeling goals..................................................................................................... 76 4.4 Designing a goal-aligned business model ..................................................... 79 4.4.1 Means templates........................................................................................ 79 4.4.2 Transformation alternatives and transformation rules ..................... 81 4.4.3 Modeling specifics ...................................................................................... 89 4.4.4 Application of the method to the eye-care health case .................... 90 4.4.4.1 Designing the goal model ............................................................... 90 4.4.4.2 Designing the goal-aligned business model ............................... 92 4.5 Summary .............................................................................................................. 96 5 Analyzing Business Collaborations to Improve Business Modeling
................................................................................................................. 99 5.1 Introduction ......................................................................................................... 99 5.2 Classifying business transactions.................................................................. 101 5.3 Creating design templates for business transaction types...................... 103 5.3.1 Future settlement-oriented, product-independent transactions .. 104 5.3.2 Future settlement-oriented, product-dependent transactions ..... 105 5.3.3 Immediate settlement-oriented, authorization-dependent
transactions ............................................................................................... 107 5.3.4 Immediate settlement-oriented, authorization- independent
transactions ............................................................................................... 108 5.4 Summary ............................................................................................................ 109 6 Designing Explorative Business Models by Analyzing Business
Collaborations ..................................................................................... 111 6. 1 Introduction ...................................................................................................... 111 6.2 Overview of the business model designing process ................................. 112 6.2.1 Eliciting resources across Open-edi business collaborationphases
..................................................................................................................... 113 6.2.2 Eliciting resources considering internal values ................................. 114 6.3 Method for designing a business model ...................................................... 116 6.3.1 Identifying business transactions ........................................................ 116 6.3.2 Identifying resources .............................................................................. 117 6.4 Application of the method to the eye-care case ........................................ 117 6.4.1 Identifying business transactions in the eye-care case .................. 118 6.4.2 Identifying resources in the eye-care case........................................ 119 6.4.3 Designing a business model for the eye-care case.......................... 122 6.5 Summary ............................................................................................................ 124 7 Using Business Models for Designing E-Services .......................... 125 7.1 Designing e-services on the MDA basis ....................................................... 126 7.1.1 Modeling business activities – business models ............................... 127 7.1.2 Modeling operational aspects of business – process models ......... 128 7.2 Designing e-services using business models ............................................. 129 7.2.1 Creating business-oriented (CIM) models ......................................... 129 7.2.2 Creating system-oriented (PIM) models ............................................ 130 7.3 Application of the method to the eye-care case ........................................ 137 7.4 Summary ............................................................................................................ 146 8 Conclusion and Discussion ................................................................. 149 8.1 Concluding Remarks ........................................................................................ 149 8.2 Comparison to similar research..................................................................... 153 8.3 Discussion about the research process ....................................................... 156 8.4 Future Research Directions ............................................................................ 160 References ................................................................................................ 163 Appendix A ................................................................................................ 171 Appendix B ................................................................................................ 179 1 Introduction
Advancements in ICT have contributed to the transformation of daily life in
large parts of the world. From a business point of view, it has transformed
traditional methods of interaction between business organizations and their
customers by providing efficient ways of performing tasks and communicating with each other. As a consequence, geographical boundaries of the world
are more and more disappearing and the demand for globalized product and
service offerings is increasing. To meet this demand, enterprises are heavily
relying on using e-business or e-commerce applications to perform their
business activities. E-business is generally referred to in situations where
enterprises use ICT to enhance any of their business processes while ecommerce generally refers to the use of ICT to perform business activities in
regard to buying and selling products and services between actors by electronic means.
Designing e-business applications consists of various steps. Among them,
identification of the required behavior of the application is considered as an
important step and is generally known as requirements elicitation. GoalOriented Requirements Engineering (GORE) techniques (e.g. goal modeling
techniques) and value-oriented requirements engineering techniques (e.g.
business modeling techniques) are widely used to elicit and model requirements for e-business applications.
In general, a business model describes actors involved in a business and
the things exchanged between them specifying, the who and what of a business. For example, who are the stakeholders of the business? What do they
offer to each other? What activities are there to create the things that the
business offers? The definitions of a business model span from simple ones
to more elaborate ones. For instance, Linder and Cantrell (2000) defined a
business model as: “the organization’s core logic for creating value”. Paul
Timmers (1998) defined a business model as: “an architecture for the products, services and information flows, including a description of the various
business activities and their roles; A description of potential benefits for the
various business actors; and A description of the sources of revenues”. Similar to Timmers’ definition above, Weill and Vitale (2001), defined a business
model as a description of different roles and the relationships played by different business partners and customers of a firm that also identifies major
flows of products, information and minatory resources among the partici15
pants. From these definitions it is clear that in business modeling the major
tasks concern the identification of resources and activities that create and
transfer these resources between the involved actors. That is, both the internal and external perspectives are considered in business modeling. In the
internal perspective the focus is on identifying business processes of an actor
that create value. In business modeling these business processes are often
called value activities and are defined as activities that are profitable to an
actor who performs them (Gordijn, Akkermans, & van Vliet, 2000). The
external perspective models activities that exchange the value, created by the
internal value creating business processes. These exchange activities are
often viewed as inter-organizational events or more precisely, as business
collaborations between actors. According to the Open-edi framework
(ISO/IEC, 2007), in business modeling, a business collaboration defines the
actors, activities for exchanging resources between them and the reciprocal
relationships between these activities.
The resources and activities that are included in a business model reflect
the intentions of business stakeholders. As such, the motivation for business
models can be found in the goals of an organization. From the business
modeling point of view, goals provide a basis for linking business strategies
to business model components. From a business perspective, a goal can be
defined as a desirable state of business that an organization wants to achieve
and hence plays an important role in defining business strategies of an enterprise. As such, in business modeling goals can be used to clarify strategies of
different stakeholders answering the "why" of the business.
In this thesis, we focus on the business modeling aspect of designing ebusiness applications. Thereby in the remaining sections of this thesis, we
limit our discussions to the business modeling and the business activities
represented in the business model level, more precisely, activities with a
higher level of abstraction which focus on producing and exchanging resources between partners and customers of an enterprise.
Over recent years, the use of business models has also been investigated
as a basis for designing e-services. Understanding the business model of an
organization is identified as critical in designing e-services and implementing them in Information Technology (IT) systems (Gordijn, Yu, & van der
Raadt, 2006a). Thereby, business models are often considered to identify eservices (Andersson, Johannesson & Zdrakovic, 2008), (Gordijn et al.,
2006a). In general, a service is defined as an abstract notion which hides
implementation details. They are also accepted among the business community as business activities that yield intangible benefits or outcomes (Baida,
Gordijn, Saele, Akkermans, & Morch, 2005). E-service, on the other hand, is
defined as the online offering of these traditional services. Various studies
have recognized the business functionalities offered by e-services as an important fact (Baida et al., 2005; Cherbakov, Galambos, Harishankar, Kalyana & Rackham, 2005). In business-oriented designing of e-services, two
16
classes of services, top-level business services and low-level e-services
which realize these business services, have been considered. Thereby, it is
important that when top-level business services are elicited and subsequently
realized them as e-services using such a top-down manner, strategic & economic aims of an enterprise are carefully considered and modeled. However, in business modeling, resource transfers only pertaining to the actual
delivery of resources are often considered (Gailly, España, Poels & Pastor,
2008). Despite this situation, it is identified that a business collaboration
between actors can span over various phases (ISO/IEC, 2002). When the
entire business collaboration life cycle is not considered in designing business models, the obtained set of e-services may not represent all possible
outcomes thus leading to the question of the completeness of the resulting eservice portfolio.
In addition to goal and business modeling, process modeling is also accepted as a prominent activity in designing e-business applications (Gordijn
et al., 2000). In contrast to a business model, a process model describes how
abstract activities described in a business model are realized as system operations. Thereby, in e-business application development, for instance in a eservice design context, it gives detailed information on the configuration of
operations by showing control flows, message transfers, etc of elicited business services. Finally, these complex process models are realized as eservices.
To summarize, from the requirements engineering perspective, designing
business models can be considered as one of the preliminary steps that identifies required system behavior in an abstract way. As such it is important
that a business model is created in such a way that clearly represents the
entire collection of business collaborations between actors, and their strategic interests. The consideration of such aspects will help to align business
goals and strategies with e-business applications and thereby achieve provisioning of economically sustainable e-business solutions.
1.1 Research problems
In recent years, exploration of business models has become an important
step in aligning business strategy with e-business applications. Recent studies in academia and industrial communities emphasize the need to explore
business models to achieve strategic alignment between business and IT
(Zlatev, van Eck, Wieringa & Gordijn, 2004; High, Kinder & Graham, 2005;
Braet & Ballon, 2007; Kartseva, Gordijn & Tan, 2007).
From a business point of view, e-business applications should help
achieving strategic interests of business stakeholders. Recent research on
business and IT alignment suggests that this can be achieved by considering
alignment between different modeling aspects such as goals, business and e17
services (van der Raadt, Gordijn, Yu, 2005; Derzsi & Gordijn, 2006; Zlatev
et al., 2004; Pijpers, Gordijn & Akkermans, 2008).
In the goal aspect, the primary concern is designing business models that
are aligned to the strategic intentions of business stakeholders. From a business modeling point of view, the formulation of the business goals should be
aligned with notions use in business modeling. Thereby, a problem here is
how to formulate strategic intentions of business stakeholders in such a way
to assist the designing of business models.
The primary concern in business aspect is to explore the value creation
process in multi-party business settings. Often exploration of the value creation process starts with the identification of key resource exchanges between
actors. However, the actual number of resource exchanges may be dependent
on various other factors such as risks, market types, settlement types, etc.
(Kartseva et al., 2007; ISO/IEC, 2002). These factors together define how
business collaborations between a buyer and seller could take place. As an
example, whether a buyer and seller accept the entry terms of the market in
advance and then commence the actual resource exchange later on, etc. From
a business modeling viewpoint, an important consideration here is to identify
a complete set of business transactions using key resource exchanges and
underlying business transactions as a point of departure. Additionally, it is
argued that business models often visualize activities pertaining to the actual
transfer of resources (Gailly et al., 2008). Thereby, a question remains about
how to consider different factors affecting business collaborations to determine and design business transactions in such a way that the business model
designing process will be better assisted.
Once the explorative business model is designed determining resource
transfers and underlying business transactions, e-services can be elicited.
From an e-service design perspective, one of the primary concerns is to design economically sustainable set of e-services. However, creating a shared
understanding of e-services and analysis of their economic viability and
technical feasibility haves been identified as key problems in developing
innovative e-services (Gordijn, van Eck & Wieringa, 2009). A number of
studies have identified the importance of using business models as a point of
departure to identify e-services (Raadt et al., 2005; Andersson et al., 2008;
Gordijn et al., 2009; Cherbakov et al., 2005). Gordijin et al. (2009) argues
that such a business model exploration process should consider intentions of
collaborating business organizations as well as consumer needs to identify
activities in which the e-services are created and exchanged. From a business
modeling point of view a lack of concern about different stages of a business
collaboration may lead to losing vital information regarding the exchange of
values between collaborating parties. From a e-service modeling perspective,
designing e-services from such business models may not define a complete
e-service portfolio. Additionally, e-service design projects are involved with
many different stakeholders such as business designers, process designers,
18
and IT-based stakeholders (Gordijn et al., 2009). Thereby, different concerns
of these stakeholders should also be addressed by the e-service design
process. As such, there is thus a problem of designing economically viable
portfolio of e-services.
Considering these aspects of business and service modeling, the basic research question can be formulated as follows:
How to design business models and e-services whilst taking into account
stakeholder intentions and business environments?
In e-business applications design, intentions stakeholders are used as a
means to describe rationale behind their external relationships with other
business partners. In systems designing, such intentions are often formulated
as goals of individual actors which are further decomposed down to subgoals and activities in a goal model. Thereby, in the basic research question
above, stakeholder intentions represent strategic business goals of actors. In
addition to goals which describe actions of an actor towards others, business
environment describes actions they perform collectively in a business constellation. As such the focus of business environment in the basic research
questions above can be set on the collaboration space where the business
collaborations between actors are seen from an independent point of view.
Considering these two aspects in the process of exploring business model
support for the provisioning of e-business solutions, we arrive at three specific research questions outlined below.
1. How to design business models considering goal models?
2. How to design business models considering business collaborations?
3. How to design e-services based on business models?
In the first two research questions, we aim to address the matter of designing strategically-aligned business models. Here, we intend to investigate
how goals of actors and different stages of a business collaboration can be
used to identify resources that these actors intend to offer each other. In the
third research question, we intend to address the matter of designing eservices using the business model as a point of departure.
These questions together address different but interrelated aspects of ebusiness applications development. In particular, the first two research questions concern the business aspect, whereas the last question concerns the
information systems aspect of e-business application development. Answering the first two questions will help business modelers to design high-quality
business models, which will support process and service designers to build
effective e-services.
19
1.2 Goals of the research
The goals that we aim to achieve in this study can thus be formulated:
1. To develop a method for designing business models based on
goal models.
2. To develop a method for designing business models based on
business collaboration models.
3. To develop a method for designing e-services based on business
models.
The goals above address research questions presented in the previous section. For instance the problem of aligning business strategies and business
models in the first research question in Section 1.1 is achieved by developing
a method that considers other forms of enterprise models such as goal models.
1.3 Purpose of the research
The purpose of this research can be described as an effort to support business
modelers as well as process and services designers by providing them with
methods that will help them execute their tasks effectively.
The purpose of the first two goals, that is methods for designing business
models, is to help business modelers by providing them with methods for
business modeling. These methods should help them to:
a. ground business model design decisions on goals of actors; and
b. ground business model design decisions on different aims of business collaborations.
From a business modeler’s point of view, grounding business model design
decisions on goals will provide traceability between goals of actors and
business model components. Since goals are easily understandable to business users, a business modeler will find it easy to explain the designed business model and justify design decisions to the business users. Additionally,
when different aims of business collaborations are considered in business
modeling, it will provide a business modeler with a way of identifying different types of resource offerings and possible relationships between them.
This will help business modelers to better represent a business case at hand
by identifying any additional actors required to offer a certain resource. Having a complete understanding of how values could be created at different
stages of a business collaboration could also help a business modeler to identify a comprehensive set of resources across the entire life-span of the business collaboration and design an explorative business model (i.e. a business
model which captures all the vital resource exchanges across the lifespan of
a business collaboration).
20
This traceability from business model components to the goals of actors
could also help process modelers to get a better understanding of abstract
business activities represented in a business model and to decide the way
they should be represented in a process model.
In a competitive market, identifying economic viability of business services is becoming a prerequisite for implementing them as e-services using,
for instance Web Services technology. A method for designing e-services
based on a business model could help service designers by providing them
with a structured way of designing an economically sustainable service portfolio. The method would also enable traceability by founding the e-services
on economic value offerings across the lifespan of a business collaboration.
As such, a service designer would be able to design a comprehensive set of
economically sustainable e-services by thus improving the overall performance of actors involved in the business collaboration.
1.4 Research methodology
A design of a research study begins with choosing a problem to address and
a paradigm in which the research is conducted. A paradigm defines philosophical and scientific methodological foundations in which a research
process takes place (Morgan, 1983). It provides a platform in which researchers can interpret or explain their research. This platform is often described as a particular view of the “world” or worldview of the researcher
(Guba &Lincoln, 1994). In the research work presented in this thesis, we
have used the design science, (Hevner, March, Park & Ram, 2004), research
approach for building artifacts to address the questions presented in Section
1.1.
Scientific research in the field of IT encompasses both knowledgeproducing and knowledge-using activities (March & Smith, 1995). According to Hevner et al. (2004), much of the research in the information systems
discipline can be classified into two paradigms: behavioral science and design science where the behavioral science paradigm focuses on the extension
of knowledge and the design science paradigm focuses on the extension of
human and organizational boundaries by building artifacts. The goal of behavioral science is truth in the sense that it aims at extending and improving
our knowledge about existing human and organizational aspects of information systems, including their development, management and use. In contrast,
the goal of design science is utility in the sense that it seeks to create innovations, including models and methods, for supporting the development, management and use of information systems.
In contrast to the behavioral science, the technology orientation of the design science paradigm makes its goal to create artifacts that serve human
purposes. March and Smith (1995) classify design science research out21
comes into constructs, models, methods, and implementations that can be
used to understand and successfully develop information systems in organizations. According to March and Smith, constructs are basic language concepts which conceptualize the problem within the domain. Model describes
solution by inter-relating the problem and the various constructs in the solution space. Further, they state that methods describe how various constructs
and models are related together to provide a solution and that method provides a stepwise approach to obtain the solution. Finally, instantiation is
defined as a realization of the solution. Considering the solutions that we
proposed in this thesis, that is methods for designing business models and eservices, it is obvious that philosophical and scientific methodological foundations of our work fall into design science research approach. Our work
reused existing knowledge for building artifacts (i.e. methods for designing
business models and e-services) which is different from understanding the
reality and generalizing it to a theory as in the behavioral science paradigm.
For instance, descriptive research methods such as grounded theory (Strauss
& Corbin, 1998) primarily focus on analyzing and describing the domain
which is quite different to the work that we have presented in this thesis.
Another approach that has the ability to be used in the research information
systems domain is the action research (Lewin, 1946). According to Avison,
Lau, Myers & Nielsen (1999), the action research lacks detailed guidelines
in terms of design, process, presentation, and criteria for evaluation for novice researchers to understand and engage emphasis of action research. The
focus of action research is primarily on different actions that a researcher
performs during the course of research. Choosing it as a research method
would shift the focus from artifacts creation to actions of the researcher
which was not the real focus of our research.
1.5 Research process
In the work presented in this thesis, we followed the design science approach
and therefore design science research cycles guided all our research activities. From the literature (Takeda, Veerkamp, Tomiyama & Yoshikawam,
1990; March & Smith, 1995; Hevner et al., 2004), we can identify that in
design science research, activities can be grouped into two basic sets:
a. activities concerning building an artifact; and
b. activities concerning evaluating an artifact.
According to March and Smith (1995) building represents the process of
creating an artifact whereas evaluating represents the process of determining
how well the artifact performs. Of the phases: awareness, suggestion, development, evaluation and conclusion of the design research cycle in (Takeda et
al., 1990), the first three can be categorized into a building step whereas the
last two phases can be put into the evaluation step. According to Takeda et
22
al. (1990) in the awareness, suggestion and development phases, identification of the problem is made, key concepts required to address the problem
are determined and candidate designs are made, respectively. In the suggestion phase, we have applied an iterative approach in the sense that artifacts
are improved over an iterative design cycle. Therefore in the awareness,
suggestion and development phases, a strategic environment which defined
the problem space was selected and the problems were identified, major
design foundations of the artifact to be built were determined, and methods
for designing business models and e-services were developed, respectively.
This process is illustrated in Figure 1 below.
Figure 1. Overview of the research process
The Awareness phase in Figure 1, represents the identification of the research Environment and defines the Problem Space. Our research environment consists of different tasks and roles associated with the e-business application development process of business organizations (see Figure 1).
Within this environment, we identified the Problem Space as business modeling and e-service design which also articulate our phenomena of interest in
the Environment. The Problem Space consists of an important task of modeling business enterprises in the process of e-business applications development. As such, we consider different dimensions such as goal models, business models and service models. Our Phenomena of interest in the Problem
Space can be summarized as: the use of goal models to support business
modeling, the lifespan of business collaboration and associated resource
transfers between involving actors, and the use of business models for eservice design (see Figure 1). These phenomena of interest represent the
23
Business needs (or the problems that needs to be addressed by business)
which are addressed by developing the methods for designing business models and e-services, the Artifacts, shown in Figure 1.
The knowledge for designing artifacts is collected in the Suggestion phase
(see Figure 1). The Knowledge Base in the figure contains knowledge about
the domain of information systems development (Hevner et al., 2004) from
which we chose the methodologies, frameworks, and constructs relevant to
design the Artifacts which provide solutions to the Business needs
represented in the Problem space. Design knowledge collected from the
Knowledge Base consists of Foundations (see Figure 1). Foundations define
the relevant methods and constructs that provide basic knowledge to design
the artifacts. Existing business modeling methods such as e3 value, Resource
Events Agents (REA) and Business Modeling Ontology (BMO); goal modeling methods such as Business Motivation Model (BRG, 2007), business
process management standards such as ISO 15944-1, 15944-4 in (ISO/IEC,
2004), (ISO/IEC, 2007) and service-oriented concepts such as e-services and
model-driven approaches for e-service design such as Model Driven Architecture (MDA) (Kleppe, Warmer & Bast, 2003) were used as foundations for
designing artifacts. Foundations provide Key concepts to design the Artifacts.
Finally, in the Development and Evaluation phases, Artifacts are developed and their contribution to solve the problems identified in the awareness
phase assessed. The Business needs from the Problem Space and the Key
concepts from Foundations are used to develop Artifacts: business modeling
and e-service design methods, are shown in Figure 1. These artifacts are
Assessed by using a descriptive evaluation considering a case from the Swedish healthcare sector (REMS) (Henkel, Johannesson, Perjons & Zdravkovic, 2007) and the Massively Multiplayer Online Games (MMOG) business
case. These cases were chosen from different business domains and concern
multiparty collaborative business environments. As such, they have provided
us appropriate testing grounds to evaluate how our artifacts contribute to,
model different activities and parties interact, while showing the different
value flows across a network of actors, and subsequently design e-services.
In particular, the Swedish healthcare sector was deeply investigated under
the REMS project (REMS) at our department. Therefore, it was easy for us
to get access to expert domain knowledge and elicit business requirements to
model the health sector business case. For the MMOG business case, we
could gather adequate amount of domain knowledge through literature reviews. In addition to evaluating the business modeling and service design
methods using the cases mentioned above, we have compared our artifacts
with similar approaches for e-business solution design and have discussed
how our methods differ from the existing approaches for business-driven eservice design. Apart from these, individual research findings were presented
24
in various scientific research forums and were refined based on constructive
feedback from the reviewers.
A detailed discussion of the research work, utilizing the framework proposed by Hevner et al. (2004), is presented in Section 8.3.
1.6 Publications
Different research studies included in this thesis are published in various
scientific forums. In this section, we provide an overview of the research
publications.
1.6.1 Overview of related publications
In this section, we present the overview of publications that are used in the
work presented in this thesis. Considering the concepts and methods, and
refinement of these concepts and methods within several publications, we
have grouped them into several collections. Under each publication collection, we briefly explain the contributions of the papers of the collection and
the author’s specific contribution to the publications. Additionally, we also
state the contribution of each publication collection to the goals of the thesis.
Publication Collection 1: Analysis of Business Notions
Paper 1
Towards a Common Business Ontology
Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T., Johannesson,
P., Bertrand G., Michael S., Dubois E., Abels S., Hahn A., Gordijn J., Weigand H. and Wangler B. (2006). Towards a Common Business Ontology, In
Michele Missikoff, Antonio De Nicola, and Fulvio D’Antonio (Ed.), Third
Open Interop Workshop on Enterprise Modelling and Ontologies for Interoperability (co-located with CAiSE 2006), (pp. 643-564), Luxembourg:
CEUR Workshop Proceedings.
Paper 2
Towards a Reference Ontology for Business Models
Andersson B., Bergholtz M., Edirisuriya A., Ilayperuma T., Johannesson P.,
Gordijn J., Grégoire B., Schmitt M., Dubois E., Abels S., Hahn A., Wangler
B. and Weigand H. (2006). Towards a Reference Ontology for Business
Models. David W. Embley, Antoni Olivé and Sudha Ram (Ed.), 25th International Conference on Conceptual Modeling (ER-2006), (LNCS Vol 4215,
pp. 482-496). Berlin: Springer-Verlag.
25
The above listed publications analyze three well-established business modeling frameworks: REA ontology, BMO, and e3 value ontology.
These publications have three main contributions. First, a model which
includes vital constructs covering different business model frameworks is
introduced. This includes an analysis of components of a resource transfer:
the right transfer, the custody transfer and evidence document transfer and
an analysis of events: conversion events and transfer events. Additionally,
their contributions also include mappings that are used as a means to relate
similar business notions in these different business modeling frameworks.
This publication collection contributes to achieve the first two goals defined in Section 1.2. It identifies different components of a resource transfer
that we have used in the methods for designing business models.
The author contributed to all parts of the first two papers. In particular,
the author has mainly contributed to the analysis of the components of a
resource transfer and analysis of events.
Publication Collection 2: Aligning Goal and Business Models
Paper 3
On the Alignment of Goal Models and Business Models
Andersson B., Bergholtz M., Edirisuriya A., Ilayperuma T., Johannesson P.,
Zdravkovic J. (2007). On the Alignment of Goal Models and Business Models, A Paper presented at the REA 25: A Celebration of the REA Enterprise
Ontology Conference, Newark, Delaware, USA. Retrieved 10 April 10 2009,
from http://www.aisvillage.com/rea25/program/andersson.pdf
Paper 4
Using Strategic Goal Analysis for Understanding and Enhancing Valuebased Business Models
Andersson B., Bergholtz M., Edirisuriya A., Ilayperuma T., Johannesson P.
and Zdravkovic J. (2007). Using Strategic Goal Analysis for Understanding
and Enhancing Value-based Business Models, In Jaap Gordijn, Maya Daneva (Ed.), Second International Workshop on Business/IT Alignment and Interoperability (co-located with CAISE 2007), (pp. 413-420), Norway: TAPIR
Academic Press.
Paper 5
Enterprise Sustainability through the Alignment of Goal Models and Business Models
Andersson B., Bergholtz M., Edirisuriya A., Ilayperuma T., Johannesson P.
Zdravkovic J. and Jayaweera P. (2008). Enterprise Sustainability through the
Alignment of Goal Models and Business Models, In Proceedings of Third
International Workshop on Business/IT Alignment and Interoperability (co-
26
located with CAISE’08), (CEUR Vol. 336, pp. 73-87), France: CEUR Workshop Proceedings.
These three papers discuss a methodology for designing goal-aligned
business models. Starting from an initial simple business scenario, the papers further discuss how to identify additional business model components to
design an enhanced business model. They introduce a set of semi-formal
design templates for defining goals and means to build a goal model for an
enterprise. Furthermore, the method also introduces guidelines for identifying business model elements based on goals and means in the goal model.
Aligning goal and business models is carried out in two steps. In step one,
the goals of an enterprise and its stakeholders are elicited and means for
realizing these goals are identified. Means templates are then used to formulate the course of actions to realize the elicited goals. In the second step, the
goal model, designed in the first step, is used as the basis for identifying
elements of a business model. A set of guidelines to identify a basic set of
business model elements associated with each means template is used in this
step to get the goal-aligned business model.
These papers have two main contributions. One of them is a set of design
templates to formulate goals and means. The other contribution is a set of
transformation rules that defines a basic set of business model components
associated with each template. These contributions together provide the basis
for achieving the first goal presented in Section 1.2.
In papers three and five, the author was the main contributor for identifying and defining the structure of means templates and defining transformation rules to map means templates to business model elements and developing a goal-aligned business model. In paper number five, the author primarily contributed to defining transformation rules to map means to business
model elements. He also contributed to defining means template.
Publication Collection 3: Exploring Business Collaborations
Paper 6
Modeling Business Transactions from the Value and Collaboration Perspective
Ilayperuma T., Zdravkovic J. (2009). Modeling Business Transactions from
the Value and Collaboration Perspective, In Hans Weigand, Hannes Werthner, Graham Gal (Ed,), Fourth International Workshop on Business/IT
Alignment and Interoperability (co-located with CAISE 2009), (CEUR Vol.
456), Netherlands: CEUR Workshop Proceedings.
27
Paper 7
Exploring the Business Value Models from the Inter-organizational Collaboration Perspective
Ilayperuma T., Zdravkovic J. (2010). Exploring the Business Value Models
from the Inter-organizational Collaboration Perspective, In Proceedings of
the 7th Enterprise Engineering Track at the 25th ACM Symposium on Applied Computing, (ACM SAC 2010), (pp. 99-105). New York, USA: ACM.
In papers six and seven, a structured method to design business models is
studied. In these papers we investigate the lifespan of business collaborations
and different objectives that these collaborations aim to achieve. Based on
the findings we propose:
a. a classification of business transactions; and
b. a systematic way to identify potential resource exchanges.
The papers have two main contributions:
a. classification of business collaborations and identification of
business transactions; and
b. identification of potential resource exchanges along different
phases of a business collaboration.
The author was the main contributor to these papers.
Publication Collection 4: Business Model Support for e-Service Design.
Book Chapter
Exploring Business Value Models for E-Service Design
Zdravkovic J., Ilayperuma T. (2010) Exploring Business Value Models for
E-Service Design. In Janis Osis & Erika Asnina (Ed.). Model-Driven Domain Analysis and Software Development: Architectures and Functions,
Hershey, PA: IGI Global,
In this book chapter, we propose a MDA-based approach to design eservices which may be implemented using Web services and Web service
coordinations. The chapter focuses on an explorative analysis of business
models for e-service design. In this approach, we propose to use business
models at the Computational Independent Model (CIM) level in the eservice design process. The CIM level business model is then transformed
into the Platform Independent Model (PIM) level, by utilizing well-defined
mappings.
Major contributions of this chapter include proposing a value based eservice design method, developing the CIM, and defining transformation
rules from CIM to PIM.
The author contributed to all parts of the chapter with the main contribution being in developing value based CIM and the transformation rules from
CIM to PIM.
28
Figure 2 below illustrates individual support of different publication collections to the thesis goals in Section 1.2.
Figure 2. Overview of the contributions of the publication collections to the research goals
1.6.2 Other Publications
Below, we list publications that are not included in the work presented in
this thesis. In the publications with more than two authors, the author list is
sorted in alphabetical order either from the first position or from the third
position onwards.
Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T. and Johannesson, P. (2005). A Declarative Foundation of Process Models, In Pastor, Oscar; Falcão e Cunha, João (Ed.), 17th Conference on Advanced Information
Systems Engineering (CAiSE 2005), (LNCS Vol. 3520, pp. 233-247), Berlin:
Springer-Verlag.
Weigand H., Johannesson P., Andersson B., Bergholtz M., Edirisuriya A.
and Ilayperuma T. (2006). On the Notion of Value Object, Dubois, Eric;
Pohl, Klaus (Ed.), 18th International Conference on Advanced Information
Systems Engineering (CAiSE06), (LNCS Vol. 4001, pp. 321-335), Berlin:
Springer-Verlag.
29
Weigand H., Johannesson P., Andersson B., Bergholtz M., Edirisuriya A.
and Ilayperuma T. (2007). Strategic Analysis Using Value Modeling: The
c3-value Approach, In Proceedings of the 40th Hawaii International Conference on Systems Science (HICSS-40). (CD-ROM/Abstracts Proceedings,
175), Waikoloa, USA: IEEE Computer Society.
Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A.
and Ilayperuma, T. (2006). Value Object Analysis and the Transformation
from Value Model to Process Model, In Guy Doumeingts, JörgMüller,
Gérard Morel and Bruno Vallespir (Ed.), 2nd International Conference on
Interoperability of Enterprise Software and Applications (INTEROP-ESA
2006), (Enterprise Interoperability: New Challenges and Approaches, pp. 5565), London: Springer-Verlag.
Ilayperuma T. (2006). A Declarative Approach of Process Model, In Hervé
Panetto, Nacer Boudjlida (Ed.), Interoperability for Enterprise Software and
Applications: Proceedings of the Workshops and the Doctorial Symposium
of the 2nd International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA’06), (pp. 315-319), London, UK:
WILEY Online Library.
Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A.
and Ilayperuma, T. (2008). Value-based Service Design Based on a General
Service Architecture, In Proceedings of Third International Workshop on
Business/IT Alignment and Interoperability (co-located with CAISE’08),
(CEUR Vol. 336, pp. 88-103), CEUR Workshop Proceedings.
Ilayperuma, T., Zdravkovic, J. (2009). Value-Based Risk Management for
Web Information Goods, In Sushil K. Prasad, Susmi Routray, Reema Khurana and Sartaj Sahni (Ed.), Third International Conference on Information
Systems, Technology and Management (ICISTM-09), (Communications in
Computer Science, pp. 64-75), Berlin: Springer.
Zdravkovic, J., Ilayperuma, T. (2010). Exploring REA and Open-edi Business Frameworks for Service Modeling, In Michaël Petit, Graham Gal, Annick Castiaux (Ed.), Fifth International Workshop on Business/IT Alignment
and Interoperability (co-located with CAISE’10), (CEUR Vol. 599, pp. 106119), CEUR Workshop Proceedings.
Zdravkovic, J., Ilayperuma, T. (2010). A Model-driven Approach for Designing E-Services Using Business Ontological Frameworks, In Proceedings
of Fourteenth International EDOC Conference (EDOC 2010), IEEE Computer Society, Accepted.
30
1.7 Disposition
The thesis is structured as follows.
Chapter 2 provides an overview of the background for the research work
presented in this thesis. In this chapter, we first provide a general introduction to the field of Requirements Engineering. We then discuss goal modeling in detail and give an overview of goal modeling techniques in the business modeling method presented in Chapter 4. A detailed discussion of the
existing business modeling methods followed by an overview of different
frameworks for business collaborations modeling is also presented. The
chapter also provides a discussion on the notion of service and recent developments in the business-oriented e-services exploration. We conclude the
chapter by presenting business scenarios use to elaborate the application of
the artifacts developed in this research work.
In Chapter 3, we analyze the business notions resource, resource transfers
and conversion activities as a part of addressing research questions two and
three regarding business models. We conclude the chapter by identifying
different components associated with a resource transfer as a part of addressing research questions two and three.
The solution to the first research question is presented in Chapter 4. In
this chapter, we discuss how a goal-aligned business model can be created
using a goal model as an input (see Figure 3). We propose a set of templates
for formulating means associated with goals in a goal model. Additionally,
in this chapter, we provide a set of transformation rules that explain how
business model components can be derived from the means templates in a
goal model. We conclude the chapter by showing the application of the method to a business scenario presented in Chapter 3.
The second research question is addressed in Chapter 5 and Chapter 6.
In Chapter 5, we provide a classification of business transaction types as a
part of answering the research question: “how to design business models
considering business collaborations” (see Figure 3). We identify four types
of business transactions considering the underlying goals of their respective
business collaborations. Each of these transactions is explored along Openedi phases of a business collaboration to identify resources and resource
transfers associated with them. We use these transaction types and associated
information about possible resources and resource transfers to propose a
method for designing explorative business models in Chapter 6 (see Figure
3). Here, in addition to the classification of business transactions in Chapter
5, we use the goal-aligned business model in Chapter 4 as an input. A set of
guidelines are presented in Chapter 6 to assist the designing of an explorative business model. Chapter 6 is concluded by presenting the application of
the method utilizing a business scenario discussed in Chapter 3.
Our solution to the third research question is presented in Chapter 7.
Here, we present a model-driven approach for designing e-services (see
31
Figure 3). We propose to use the business model as the point of departure for
identifying an economically sustainable set of e-services. A set of high-level
transformation rules are proposed to assist the transformation between business-oriented computational independent models and technology independent system-oriented models (see Figure 3). We also explore the applicability of the method by applying it to the running business scenario used in
Chapter 6.
In Chapter 8, we provide concluding remarks by discussing how we have
addressed research questions and goals. The chapter also discusses the research process based on guidelines for design science research by Hevner et
al. (2004).
Figure 3. Overview of design artifacts in relation to the goals
32
2 Background and Related Work
With the competition among business organizations and Internet-based business increasing, there is a demand for innovative ways of precisely modeling
businesses and obtaining a complete set of requirements to support the development of e-business applications. Recent developments in the field of
requirements engineering especially in the fields of enterprise modeling such
as goal, business and service modeling focus on achieving this goal.
In this chapter, we explain the requirements engineering process in Section
2.1. Then, we focus on the different models used in enterprise modeling.
Accordingly, in Sections 2.2, 2.3, and 2.4 we give an overview of goal modeling, business modeling and different business collaboration frameworks
developed based on business modeling methods. In Section 2.5, we introduce important concepts related to e-service design and give an overview of
related work on business-oriented e-service design in Section 2.6. We conclude the chapter by introducing running business scenarios in Section 2.7.
2.1 Requirements engineering
Requirements engineering is an important aspect in the information systems
development process. There, it is regarded as the process of determining the
stakeholders such as users, customers, suppliers, etc., their business needs
and required system behaviors to satisfy these business needs. Requirements
are used for a variety of purposes including project scoping, cost estimation,
scheduling of activities, designing and testing of software, etc. (McEwen,
2004).
A stable set of requirements is a prerequisite for the development of a
quality software system. Poor requirements that are weakly organized, expressed, or even weakly related to stakeholders are causes of failing (Hull,
Jackson & Dick, 2004; McEwen, 2004). The success of any information
system depends on its acceptance by customers and users as a system that
functions up to the standard they expected. As such proper identification of
requirements has been recognized as critical for the successful developments
of systems.
In general, the requirements engineering process encompasses activities
related to four phases: requirements elicitation, requirements negotiation,
requirements specification and requirements validation (Pohl, 1996). They
33
are performed sequentially and are also interlinked. The overall aim of these
phases is to discover the critical inputs for the system development process.
The process of building an information system starts with collecting information such as the stakeholders of the system and the required system
behaviors in the requirements elicitation phase. Identification of stakeholders, their goals that loosely denotes the objectives the system must meet and
tasks that users intend to perform with the system are three important aspects
in requirements elicitation (Nuseibeh & Easterbook, 2000). Different types
of techniques are used to elicit requirements. They range from traditional
techniques such as questionnaires, surveys, interviews to model-driven techniques. These model-driven techniques include goal-based methods, scenario-based methods, etc. (Kavakli & Loucopoulos, 2004). The elicitation of
requirements requires a strong understanding of the business environment,
including identification of its activities, stakeholders and their needs. It involves a high level of interaction with the system stakeholders and requires
understanding of complex social relationships of system stakeholders, the
specific roles they play within the functions of the system to be developed.
The identification of system boundaries is one of the important aspects of the
elicitation phase and this affects identification of user groups, tasks, etc.
(Nuseibeh & Easterbook, 2000). They further state that the elicitation
process should be capable of identifying a diverse set of needs from different
groups of users of the system to be built. The stakeholders may express their
needs in a variety of ways. They can express their needs in more general
ways in terms of goals they want to achieve (McEwen, 2004). For instance, a
stakeholder may need to streamline helpdesk application support to deal with
the high amount of help requests received by them over phones. The developer team may then translate this stakeholder need to a distinct system feature. It is also possible for a stakeholder to express their needs in a more
specific way by expressing them as required system features (McEwen,
2004). For example, the same stakeholder may express that he requires a
Web-based system which enables customers to enter their own support requests. In this case the stakeholder translates his need into a more distinct
system feature. Whatever the way stakeholders use to express their needs,
the developers should be capable of understanding these needs and correctly
interpreting them. The success of this entire process depends on the ability of
the system developers to correctly understand the business environment and
collect a precise set of requirements from system stakeholders (Loucopoulos
& Kavakli, 1995).
The aim in the requirements elicitation phase is to elicit the requirements.
As such at the end of it, a large quantity of information regarding the system
stakeholders, their business needs and system functions required by them is
available. This information has to be carefully analyzed to resolve conflicts
among requirements and to agree on a proper set of requirements that precisely represents the business environment, business needs, etc. The analysis
34
process not only captures a precise set of requirements but also establishes
the relationships among them. Different kinds of modeling techniques are
employed in this phase to help the analysis process. For instance, enterprise
models and goal models are used in this phase to agree on requirements,
identify and resolve conflicts and establish relationships among the elicited
requirements (Kavakli & Loucopoulos, 2004; Loucopoulos & Kavakli
1995).
In the requirements specification phase, the negotiated requirements are
documented in a formal way by specifying, for example, the stakeholders,
their roles and business goals to required system functions. This is done by
means of systematically relating elicited requirements to system functions.
Documentation is done by using, for instance, natural language or formal
specification languages. Similar to previous phases, different techniques, for
instance, goal-based techniques such as Knowledge Acquisition in Automated Specification (KAOS) and Goal-Based Requirements Analysis Method (GBRAM), are used to relate business level goals to functional and
non-functional requirements at the system level (Kavakli & Loucopoulos,
2004). Given the formal nature of requirements specifications, they provide
a vital base for validating requirements and for designing the system. IBM
(McEwen, 2004) suggests that the requirements can be captured by using
three main types of documents: stakeholder needs, software features, and
software requirements specification. This, they argue, simplifies the process
of requirement reviews and allows for better accountability since it separates
different aspects of requirements along different documentations. This provides freedom for different readers to focus on different parts of the system
development process. These documents gradually refine stakeholder needs
and the required software features in the problem domain to the more specific software requirements in the solution domain.
Finally in the requirements validation phase, measures are taken to ensure
that the correct system is developed. Requirements validation generally requires all the actors involved in the system development, to assess requirements specifications and agree on their correctness. This is to ensure that the
requirements specifications, which provide the basis for designing a system,
accurately specify the actual needs of system users, customers, the current
business environment, the future business needs, etc. The validation process
usually goes through the models, use cases, prototypes, etc, developed in the
specification phase to identify if requirements are weakly or incorrectly interpreted during the elicitation, analysis or modeling. The validation of requirements is extremely important to increase effectiveness during the system development and during its actual use. Incorrect or weakly captured
requirements lead to difficulties in the development process and will also fail
to meet the actual demands of the business.
The phases discussed above explain the role requirements engineering
plays in system development. In-depth understanding of the current business
35
processes and the future needs is required for the successful development of
a quality software system. Identifying and analyzing internal and external
requirements of business and its environment, proposing reasonable solutions and also providing means to system maintenance process in the postdevelopment stages is paramount to successful system development. Research activities in requirements engineering is distributed along two main
paths (Nuseibeh & Easterbook, 2000). The theoretical path provides the
frameworks to guide the collection of requirements and assess the feasibility
of them in the early phase of the software development. The practical path,
on the other hand, provides the tools to develop the required software solutions. In recent years, much of the research in the field of requirements engineering has focused on goal and value-oriented methods, especially for requirements elicitation, modeling and validation. These approaches utilize
goal and business models as a means of representing and visualizing business requirements in the systems development process. For example approaches such as KAOS (Dardenne, Lamsweerde & Fickas, 1993), Tropos
(Mylopoulos & Castro, 2000) and i* (Yu, 1995) provide goal-oriented methods for identifying, modeling and analyzing business requirements and
approaches such as e3 value, REA provides value-oriented methods for identifying and modeling business environments.
2.2 Goal models
Goal-oriented requirements engineering (GORE) methods have received
much attention, particularly, in recent years. They concern adding on features such as motivation and traceability to the systems development process
by means of linking general business needs down to more specific system
components. In GORE, one of the prime aims is to justify and explain the
choice of selected requirements and their relationship to system functions.
As such, instead of directly concentrating on what the system needs to do,
GORE methods first focus on exploring why a certain system functionality is
required and how it can be implemented.
Goals are formulated at different abstraction levels. Goals with a highlevel of abstraction, which are often called top goals, concern the long-term
strategic interests of an organization and its stakeholders. The scope of these
goals often spans over the present environment and the system to be modeled (van Lamsweerde, 2001). Goals are also formulated with low-level abstraction. However, this distinction between high and low level goals is often
unclear. Goals are considered as important in the requirements engineering
process for various reasons (van Lamsweerde, 2001). As an example, goals
provide a means to assess the completeness of requirements specification.
Here completeness is assessed in respect to a set of goals by considering
whether or not the specification provides all the means to achieve each and
36
every goal in the set. Additionally, goals also help to avoid irrelevant requirements by assessing whether or not the specification of a requirement is
useful to achieve at least one goal. Furthermore, they provide a means to
explain technical requirements to the business users by mapping the lowlevel technical requirements to strategic business goals. The separation of
concerns is another important characteristic which goals provide to the requirements engineering process. For instance, with respect to a high-level
goal, corresponding low-level technical requirements to achieve it, tend to
evolve with time by finding different ways to achieve the goal. Hence, separating volatile technical requirements from strategic goals makes the whole
system more flexible and stable in the sense that different refinements can be
introduced and linked to a common set of goals rather than changing strategic goals themselves.
Based on how goals contribute to identifying system components, they
have been classified along different axes. Goals that lead to functional requirements and goals that lead to non-functional requirements are two main
classifications axes proposed in the requirements engineering literature.
Goals which lead to the identification of functional requirements are called
functional goals or hard goals and goals which lead to non-functional requirements are called non-functional goals or soft goals. The functional
goals represent the class of goals that can be established or achieved in a
clear-cut sense while non-functional or soft goals represent the goals that
concern the business process qualities such as security, accuracy, etc. Further, goals are also classified based on temporal behaviors laid down by
them. For instance, four generic types of goals: achieve, cease, maintain and
avoid in KAOS (Dardenne et al., 1993), are identified based on the target
behavior prescribed by them on the future states of the system.
In addition to the different classification axes discussed above, goals are
also characterized by different attributes such as their names and priority
order, etc. attached to them (van Lamsweerde, 2001). Further, goals are interrelated to each other through different types of links. For instance,
AND/OR refinements to establish a parent-child relationship between goals
(Dardenne et al., 1993). These refinement links define that a parent goal can
be achieved by achieving all or any of its child goals.
From the requirements engineering point of view, a goal defines a set of
desired behaviors of the system under consideration (van Lamsweerde,
2001). From the business point of view a goal defines a desired state that a
business organization wants to achieve (Andersson et al., 2008). The first
definition seem to be bit more specific and links goals towards a set of states
or simply saying, a set of different ways to reach the goal. This kind of systems thinking gives a goal much more weight in the sense that they are lot
more implementation-oriented and if the development process fails to
achieve it, then the system may not meet the requirements set by the stakeholders. Business goals may be adjusted over time to meet the changing
37
requirements of business and its environment. Along the development
process, system developers elicit these strategic business goals from the businesss stakeholders and refine them to more specific system-oriented goals
and further down to desired system functionalities. Much of the recent work
focuses on linking these two views together to have a structured goaloriented approach in the context of systems development. Kavakli et al.
(2004) argue that goal analysis contributes to every phase in the requirement
engineering process discussed previously (see Table 1). The table below
shows that the goal analysis is used in every sphere in the requirements engineering process and offers benefits in almost every stage in the requirements engineering process. Yet, there is no single approach that describes
the overall role of goal analysis in the requirements engineering process
(Kavakli & Loucopoulos, 2004).
Table 1. Goal contribution in the requirements engineering process (adapted from
Kavakli & Loucopoulos, 2004)
RE Activity
Requirements elicitation
Requirements negotiation
Requirements specification
Requirements validation
Goal Analysis Contribution
1. Understanding the current organizational situation.
2. Understanding the need for
change.
3. Providing the deliberation context of the requirements engineering process.
4. Relating business goals to functional and non-functional system components.
5. Validating system specifications
against stakeholders’ goals
The table above shows that, in requirements elicitation, goal models are used
as a means of explaining and understanding present and future situations of a
business organization. More often, they are used to explain the business
strategies of an organization and intentions of participating actors. For instance, goal modeling techniques such as i* (Yu, 1995) and Enterprise
Knowledge Development (EKD) (Kavakli & Loucopoulos, 1999) are used in
the requirements elicitation phase for modeling the current and expected
future of organizations. Equally, in negotiation, specification and validation
phases of requirements engineering, goal modeling techniques are used to
reason about the need for the changes in the business context, to help identify required system components to implement the changes and to provide a
means to conform that identified functionalities are aligned to stakeholder
goals. The objectives of the different phases of requirement engineering are
38
not similar. For instance the earlier phases aim to collect interests of stakeholders, the ways to address or compromise them and so on. In contrast, the
latter phases focus on more complete design decisions, consistency between
collected requirements, validating them against the stakeholder interests and
so on. As such, the techniques used in early and latter phases on the requirements engineering process are different from each other (Yu, 1997).
The goal modeling techniques used in the early phases of requirements
engineering focus on aligning business strategy with IT systems. As explained earlier, goal models have been extensively used to model and analyze organizational business strategies in the early phases of businessoriented information systems development. For instance, the i* (Yu, 1995)
and Business Motivation Model (2007) are two such techniques that focus
on modeling business activities, relationships among them and reasoning
their behaviors.
Among them, the i* (Yu, 1995) approach models goals, tasks, resources
of different actors and the dependencies of these elements to the actors in
strategic multi-actor collaborative contexts. It is used to build strategic goal
models to describe existing business environments in multi-actor collaborative contexts and to resolve conflicts and improve existing business relationships. The i* approach consists of two main modeling components, the Strategic Dependency (SD) model and the Strategic Relationship (SR) model.
The former is used to describe the various dependencies among the collaborating actors in the modeling context while the latter is used to describe the
interests among them. Actor is the central notion of i* approach. By modeling their beliefs, abilities commitments and various dependencies among
them, the approach explores the avenues to achieve different goals that may
be difficult to achieve a single actor alone. Kavakli (2002) argues that the i*
approach consists of three main steps. Firstly, it focuses on identifying and
modeling existing business processes. Secondly, it analyses the model and
identifies required changes. Finally, it proposes new processes to make the
relevant changes. That is, modeling begins by identifying an as-is business
state, strategic dependencies among business actors, goals and tasks. Next,
the model developed in the previous step is analyzed to check whether or not
the existing processes support achieving actors’ goals and to identify alternative configurations to the dependencies among the actors. Finally, the to-be
model is developed by introducing new processes to support achieving unsatisfiable goals identified in the previous step.
In contrast to i* methodology, BMM proposed by Business Rules Group
(BRG) provides a scheme for business-driven requirements development
(BRG, 2007). It helps to articulate factors to motivate business strategies, to
define important elements in these strategies and to identify the relationships
between them in an organization. The BMM explores the business environment of a single actor and consist of three principal modeling components:
Ends, Means and Influencers.
39
In BMM, an End defines things that a business seeks to achieve without
actually referring to how they will be materialized. Vision, Goal and Objectives are three important elements defined by an End. These elements formulate business intentions at different levels of granularity. Among these elements, the Vision defines a general business intention which describes the
future state that the business wishes to achieve, for example: “to be the
brand of choice of customers”. Goal on the other hand defines a state or
condition that the business wishes to achieve or sustain. In contrast to Vision,
which is broad, Goal is focused. A typical goal of an online retailer could be:
“to have a large customer base”. However the margin between them may
be too narrow so that to distinguish between a vision and a goal, in depth of
knowledge of the business context may be required. The third important
element in End is Objective. With compared to Vision and Goals, Objectives
are time-targeted and measurable, for an example a typical objective of a
business could be: “six percent increase of sales within one year”.
Compared to the End, Means represents any capability or an instrument
that can be used to achieve Ends. Means can be of two forms; they can be
formulated as a Course of Action which describes how goals are realized.
For instance, “implement a reward scheme” could be a means to have a
large customer base. Directive is the other form of Means and defines conditions that govern a Course of Action. For instance “rewards should be based
on number of purchases” may govern the course of action, “implement a
reward scheme”. Given the concrete nature of Means, it can be easily argued
that they represent leaf nodes of a goal hierarchy.
The other major component in BMM is an Influencer. An Influencer is
anything that is capable of producing an impact on achievement of means.
An Influencer can either be external or internal factor. For instance, it could
be external factors such as environment or government regulations: “customers prefer businesses with reward schemes” could be an environmental
influencer to the means stated in the previous section.
According to BMM (BRG, 2007), the components discussed above together explain two things:
a. the things needed to achieve organizational business intensions; and
b. the reasons for the existence of elements in the developed model.
The former deals with identification of Means necessary to achieve desired Ends. The latter identifies the Ends served by Means and Influencers
that justify the modeling decisions.
These different goal modeling techniques and schemes provide instruments for identifying existing business strategies and defining new business
strategies. Yet, goals and means are difficult to formulate and can span over
different abstraction levels. For instance, they could represent value propositions of organizations up to their intentions of general economic sustainability. Since both modeling domains are closely related to each other, formulation of goals for example, using business notions would provide better inte40
gration and understanding of different business strategies and their choices.
Additionally, it will also help formulating goals and means in a more structured manner.
In the next section, we discuss different business modeling approaches
and their impact and usage in the requirements engineering process.
2.3 Business models
While goal models are regarded as answering the “why” of the business,
business models are regarded as explaining the “what” of the business. That
is, goal models give an overview of stakeholder intentions and business
strategies, where as business models provide a high level view of activities
taking place in and between organizations. In recent years, different channels
to interact with customers provided by the online environment have spurred
business firms to devise new ways of building and maintaining relationships
with customers to sell products and services.
The online business environment has broadened the choices that a firm
can made on how to interact with their customers. This has spurred firms to
pursue new and innovative ways of structuring their business strategies to
establish a better position over their competitors. The term business model
has been used quite frequently. Yet, there is no quite complete consensus of
how it could be defined. In general a business model is defined as “the way
of doing business” or more precisely “a model that depicts core logic behind
the business”. Many authors argue that business models try to answer questions like: who are the actors? What do they offer each other? What are the
activities that they perform to produce things, exchange them, etc? (Gordijn,
2002; Osterwalder, 2004). Gordijn, Osterwalder & Pigneur (2005) classify
the evolution of business models into several phases. They argue that in the
first phase of the evolution, the authors such as (Timmers, 1998) and (Rappa,
2001) were focused on defining and classifying business model notions. In
the next generation, the authors were more focused on identifying components of a business model but not really on describing and linking them to
each other as building blocks. An example could be the work done by Chesbrough and Rosenbloom (2002). The authors such as Weill and Vitale
(2001) and Afuah and Tucci (2001) in the third phase focused on detailed
descriptions of business models. The points of departure of fourth and fifth
phases of business model frameworks such as Gordijn (2002) and Osterwalder (2004) conceptualize the business model components in the form of
ontologies and applying them in different disciplines including information
systems and management.
One of the first attempts to define a business model includes the work
done by Paul Timmers (1998). In his work on business modeling he defines
a business model based on what is meant by it. From his definition, we can
41
identify two viewpoints: an architectural and an informational viewpoint.
From the design points of view, a business model is essentially a description
of an architecture for the flow of products, services and information which
also describes the actors involved and their specific roles. From an information point of view, a business model describes the potential benefits and
source of revenues. Timmers identifies 11 e-business models: e-shops; eprocurement; e-mall; e-auctions; virtual communities; collaboration platforms; third-party marketplaces; value-chain integrators; value-chain service
providers; information brokerage and trust; and other third-party services.
He further classifies these 11 business models according to their degree of
innovation and functional integration. The degree of innovation ranges from
simple electronic ways of doing traditional business to more innovative ebusiness activities. The functional integration dimension describes the number of functions performed by a company, for example an e-shop only provides the marketing function of a shop and therefore with less functional
integration while a collaborative platform provides an environment for collaboration between trading partners and has high functional integration.
Similar to Timmers, Weill and Vitale (2001) define eight atomic business
models where each model describes different ways of doing a business electronically. These models can be combined in multiple ways to represent different kinds of business models. The eight atomic business models defined
by Weill and Vitale are: Content Provider; Direct to Customer; Full Service
Provider; Intermediary; Shared Infrastructure; Value-net Integrator; Virtual
Community; and Whole of Enterprise.
Michael Rappa (2001) presented a more comprehensive list of business
models comprising 30 models organized into nine categories: Brokerage;
Advertising; Infomediary; Merchant; Manufacturer; Affiliate; Community;
Subscription; and Utility. These generic models classify businesses based on
the products and services they offer to their environment.
The business model frameworks presented above have a more descriptive
nature and propose different kinds of models that one can use to represent
different kinds of businesses. They are in a way exploring various kinds of
business models existing in the modern world. Other than these, there is
another approach to define a business model in a more precise way by identifying different constituent components of it. These latter approaches provide
a set of basic constructs and relationships among them in the form of ontologies.
Gordijn (2002) provides a conceptual framework called e3 value ontology
that identifies and classifies business terms based on a value-oriented approach. The approach centers between the trade of objects of value among
the various business actors. It aims at providing a simple approach for modeling value-oriented network constellations of business organizations.
Business Model Ontology (BMO) by Osterwalder (2004) provides a more
comprehensive way for modeling businesses. It identifies various business
42
concepts classified around four pillars: Product; Customer Interface; Infrastructure Management; and Financial Aspects. Altogether, these pillars aim
to define a company’s business, their customers, how they carry out delivering their value proposition, who their business partners are and how they
generate revenue. Among the business-modeling approaches we analyzed in
our research, BMO has a wider scope than other approaches and has a strategic focus.
The REA ontology proposed by Bill McCarthy (1982) has its origins in
accounting and micro-economics and has a strong theoretical background in
basic accounting principles. It centers around the concept of economic reciprocity, meaning that every economic event that increments a business’s
resources is linked with a decrement economic event. During recent years
REA has been extended to use as a foundation for systems development. For
instance, it has been used to develop a framework for model-driven development of systems (Hruby, 2006). Additionally, REA has also been used in
many e-commerce frameworks. Examples are UN/CEFACT Modeling Methodology (UMM) (UN/CEFACT, 2003) and Open-edi business transaction
ontology (OeBT) (ISO/IEC, 2007).
Having discussed different business modeling approaches briefly, we next
move to discuss three specific business modeling ontologies in detail. As
mentioned earlier, these business modeling approaches have been used in
many standardization efforts and used to model real life business cases. In
this thesis, they provide the conceptual bases for analyzing components of
resource transfer activities associated with business models.
2.3.1 Ontologies for business modeling
It was explained in the previous section that, over recent years, the conceptualizations with regards to business modeling focus on defining concepts
and relationships between them in the form of ontology. The term ontology
has its roots in philosophy. Lately, it has been used in information science,
for knowledge engineering purposes to define models specifying reusable
components and the relationships among them. The term ontology in this
thesis is used in relation to information science and therefore we follow the
definition provided by Thomas Gruber (1993).
Ontology is an explicit specification of a conceptualization, defines Gruber (1993). He further clarifies the conceptualization as an abstract simplified model of the world that we intend to represent. The aim of using ontology in information science is therefore to make a common understanding of
the given subject by describing different objects of it and the relationships
between them. In the following section, we briefly introduce the types of
ontologies in the domain of business modeling.
The ontologies related to business are developed in two branches: one is
called enterprise ontologies and focuses on describing concepts related to
43
organisational activities, structure, etc., of an enterprise (e.g. TOronto Virtual Enterprise (TOVE) project (Fox, 1992)). The other describes the concepts related to business transactions among several actors meaning that it
mainly aims to describe the activities of a network of business constellation
(e.g. BMO, e3 value). In this thesis we focus on the ontologies that describe
the structuring of business activities in a multi-party business environment.
In the domain of e-business there exist a number of ontologies that identify and classify a number of business concepts. Among them the three leading ontologies are:
• Business Model Ontology (BMO);
• e3 value ontology; and
• Resource Events Agents (REA) ontology.
Though they share similarities in the concepts used in each other, they are
expressed in different terminologies and from different perspectives. Among
them the BMO (Osterwalder, 2004) is wider in scope than the other two. It
focuses on resource exchanges between actors as well as internal capabilities
and relationships of an actor. The REA (McCarthy, 1982), on the other hand,
was originally developed as a basis for accounting information systems and
focuses on increment and decrement of resources of an actor. The e3 value
(Gordijn, 2002) aims at modeling value webs of cooperating trading partners
and also helps the profitability analysis of the modeled business scenarios.
Due to the differences in scope and underlying theoretical bases, these
business modeling ontologies use different terminologies to represent similar
business knowledge. Deeper analysis of these three ontologies shows that
there are considerable overlaps in their but at the same time there are differences between them (Currie, 2004). All three ontologies use the notions,
value and resource in the meaning that resource is used to create value.
The notions relevant to resources and resource transfers appear in BMO,
REA and e3 value ontologies. In BMO, resource represents tangible resources such as goods, intangible resources such as brand and reputation,
and human resource such as skilled labor. An activity in BMO represents
internal activities that create resources and external activities that transfer
these resources between actors. Concerning the terminologies used to
represent resources and resource transfers in REA and e3 value ontologies,
the former uses economic resource and economic events whereas the latter
uses the term value object and value transfers to represent the same business
notions. Though corresponding notions share a certain level of overlap, they
are not identical to each other. As an example, a consumer value can be a
value object in e3 value but for REA it cannot be. That is the notion of value
used by e3 value which has a broader meaning than the notion economic
resource in REA. About the terminologies economic events and value transfers, they share a similarity in the sense that both of them are used to
represent a transfer of resource from one actor to another. In addition to
44
these notions, e3 value distinguishes an activity that transfers a resource from
an activity that produces a resource by introducing the notion of value activity. REA ontology does not provide a similar notion. In addition to the above,
these ontologies define several other notions that are related to modeling
important relationships between the notions discussed above. For instance
REA uses duality to represent economic reciprocity between economic
events whereas e3 value uses the notion of value interfaces to represent the
same. Below, we explain different notions used by these three ontologies in
detail.
2.3.1.1 The Business Modeling Ontology (BMO)
BMO, proposed by Alexender Osterwalder (2004) aims to provide an approach to build business models by applying more rigorous, accurate and
detailed analysis of business activities for an enterprise. Influenced by the
Balanced Scorecard approach of Kaplan and Norton (1996) and Markides
(1999), it proposes nine interrelated concepts grouped around four pillars.
The Balanced Scorecard approach gives a set of measures that enables top
managers to get a comprehensive view to lead their business efficiently. It
identifies four perspectives of the business: customer perspective; internal
perspective; innovation and learning perspectives; and financial perspective.
The customer perspective deals with answering the question: how is a company seen by its customers? In the internal perspective, the company tries to
identify what must be done to meet the expectations of its customers. The
innovation and learning perspective aims to continue the improvement of
their existing processes, as well as abilities to expand them, to introduce new
products. Finally, the financial perspective asks the company itself about
how it is viewed by its shareholders.
Markides (1999) describes who a company should focus on whom they
target as customers, what they should offer to their customers and how they
should go about doing this. As also explained by Ostwerwalder (2004), what
is missing in this proposal is the financial aspect of a business.
In the following table Osterwalder compares the four pillars of its BMO
with a Balanced Scorecard approach and Markides’ work.
Table 2. Four pillars of BMO with two other approaches (based on Osterwalder,
2004)
Business Model Ontology
Product
Balanced Scorecard
Markides
Innovation and Learn- What?
ing Perspective
Customer Interface
Customer Perspective
Who?
Infrastructure
Man- Internal Business Pers- How?
agement
pective
Financial Aspects
Financial Perspective
45
Based on an analysis of existing business model literature, Osterwalder
proposes a new approach which is called BMO. The BMO consists of nine
elements grouped into four pillars listed above. The following table adapted
from (Osterwalder, 2004) summarizes the synthesis of BMO.
Table 3. Principle concepts of BMO (taken from Osterwalder, 2004).
Pillar
Product
Building Block
of Business
Model
Value
Proposition
Target
Customer
Customer
Interface
Distribution
Channel
Relationship
Value
Configuration
Infrastructure
Management
Capability
Partnership
Cost Structure
Financial
Aspects
Revenue
Model
Description
A Value Proposition is an overall
view of a company's bundle of products and services that are of value to
the customer.
The Target Customer is a segment of
customers a company wants to offer
value to.
A Distribution Channel is a means of
getting in touch with the customer.
The Relationship describes the kind of
link a company establishes between
itself and the customer.
The Value Configuration describes
the arrangement of activities and resources that are necessary to create
value for the customer.
A capability is the ability to execute a
repeatable pattern of actions that is
necessary in order to create value for
the customer.
A Partnership is a voluntarily initiated
cooperative agreement between two
or more companies in order to create
value for the customer.
The Cost Structure is the representation in money of all the means employed in the business model.
The Revenue Model describes the
way a company makes money through
a variety of revenue flows.
The above table not only summarizes the most commonly appearing
building blocks from various other research in the area of business modeling
46
but also shows the nine core concepts of the BMO divided into four categories similar to a Balanced Scorecard approach as well as to Markides’ work.
In the following section we briefly discuss the concepts of BMO. We limit
our focus to the first three pillars listed in the table above.
Product
The Product pillar gives a high-level view of a company’s business including a bundle of products or services offered to its customers and how it differentiates from its competitors. Basically it is comprised of two components:
the Value proposition and the Offering. The Value Proposition describes the
value offered by a company to its customer segments. It specifies a set of
products and services offered and how they are bundled together. It further
differentiates the products of a company and the way they are offered from
its competitors by pinpointing different features associated with the products, services and the way they are offered.
The Offering sub-element decomposes the aggregated view of the company’s Value Proposition, into a set of elementary components by illustrating
certain characteristics of specific products or services that describe their
position in a competitive market. The BMO uses several attributes: Reasoning; Value Level; Price level; and Life Cycle to describe why customers
should be interested in their products. It does this by specifying various aspects of having them and using them, for example, how much effort is
needed to obtain these products and the costs related to their maintenance,
etc. These attributes further specify how an enterprise differentiates its products and services from its competitors by means of explaining whether they
are unique for the enterprise, or they are an improvement over the same
competitive products and services offered by others or just the same as the
products offered by others. Furthermore these attributes illustrate the position of the prices of the products over their competitors.
Customer Interface
The Customer Interface describes the customers of a company. It primarily
aims to describe the type of customers targeted by a company, how a company reaches its customers to deliver its products and what a company does
to attract new customers and retain existing ones. Customer Interface consists of three basic elements: Target Customer, Distribution Channel and
Relationship.
Among them the Target Customer element represents the customers that a
company targets to sell their products. Segmentation of customers and identification of groups to sell products is important as to maximally utilize resources and increase profits. The Criterion sub-element associated with the
Target Customer element decomposes a company’s customers into different
segments using a set of characteristics it has, for example, of being a geographical or socio-demographic nature.
47
The way that a company delivers its value is described by the Distribution
Channel element. It describes how a company delivers its value proposition
to the Target Customers, whether it is directly by itself, for instance through
sales force or over the Internet or indirectly, for example, through intermediaries. Its purpose is to deliver the right amount of products and services to
the right people at the right time. The Distribution Channel is further decomposed down to a sub-element Link that illustrates specific marketing
tasks employed by a company to deliver its value proposition to its customers. The Link sub-element potentially describes the parts of a Distribution
Channel by looking at them from different aspects, for example, how the
usage of the Web impacts on reaching their customers or what specific functions at various stages of the customer buying cycle are fulfilled by channel
links. Moreover, the Link sub-element inherits attributes from the Offering
sub-element of the Value Proposition.
The Relationship element in the Customer Interface pillar refers to a relationship that a company builds with its customers. It is most important for a
company to have a strong customer base to be able to survive in a competitive market. For that, managing existing relationships and building new relationships is essential. The relationship building comes at a high cost and
therefore a company must carefully define the ways to do it. The BMO classifies customer relationships based on customer equity goals of a company:
i.e., acquiring, retention and add-on selling. The idea behind this classification is to treat the customer as a company’s asset and to emphasize that they
have to be maximally utilized like any other asset. As he describes, this
analysis would help companies to optimize the acquisition, retention and
selling additional products to their customers and to increase its value for the
company throughout its lifetime. To attract and keep customers, a company
must highlight the different features it has over its competitors, both of products and of delivering these products and services to the customers. The Relationship element is further decomposed into a sub-element Mechanism.
Mechanism describes the specific actions that a company takes to build a
relationship with its customers. These actions include personalization of
actions, establishing trust, and strategies of promoting the brand name.
Personalization represents building a one-to-one relationship with customers. This can be done in several ways like tailoring the marketing activities to a specific customer or to customer segments, for example, personalized product recommendations to customers. The establishment of trust can
happen in various ways. For example, a company could use a third party to
establish the trust between them and the customers. Moreover, the brand
could also play a pivotal role in attracting customers. A popular and trustworthy brand name would be an excellent way to attract and retain customers and also to establish trust with them.
48
Infrastructure Management
Infrastructure management in BMO is concerned with how a company
creates value and what abilities they should have to create and deliver value
for customers. It consists of three main elements: Capability; Value Configuration; and Partnership elements.
The Capability element in BMO refers to the ability for a repeatable use
of a company’s assets to create and offer their products and services to the
market. Since the resources are scarce, frequently, capabilities are outsourced to partners of a company. The use of e-business technologies
enables a firm to have a tight integration between outsourced capabilities for
them to function properly.
Capability is further decomposed down to Resource and Actor subelements. A Resource is an input to the value creation process of a company
and acts as a source of a company’s capabilities. They can be tangible like
equipment, intangible like brand names of a company, or human resources
like a skilled labor force. An Actor in BMO is an outside organization. More
precisely, it is meant for company’s trading partners and is not equivalent to
the Target Customers. The company, together with its partners, offers products or services to the target customers.
The Value Configuration element shows all the activities necessary for
the creation of value and specifies the relationships among them. It
represents all the activities, both inside and outside and extends the Porter
value chain (Porter, 1998) by two other types: value shop and value network.
The activities in the value shop describe the activities ranging from understanding a problem to be solved, finding alterative solutions, evaluating them
and choosing among them up to implementing a solution and measuring its
successfulness to solve the problem. The activities of the value network describe the activities associated with selecting and inviting customers to join
the business network, managing contracts related to a mediation, establishing, marinating and terminating links between them and keeping the network
on alert to serve customer requests.
In BMO, Partnership is defined as a voluntarily initiated cooperative
agreement between several companies to jointly create value for the customers by coordinating their core competencies. It describes the configuration of
activities between a company and its partners and the distribution of resources between them.
In order to work partnerships properly, the terms and conditions for working together must be clearly defined. For that, BMO defines an Agreement
sub-element which aims to explain the motivation behind a partnership and
the conditions under which the parties will cooperate with each other.
It explains the motivation from several aspects: establishing partnerships to
get access to infrastructure facilities, to expand the business operations, to
reduce risks and to get access to resources like knowledge, data, etc. Furthermore, an agreement describes the importance of partnering with another,
49
the degree of competition between them and how close they are linked together.
2.3.1.2 e3 value ontology
The e3 value ontology proposed by Gordijn (2002) focuses on describing the
value creation and transfer process in a business network constellation. He
argues that the main goal of business modeling is to answer the question:
“who is offering what to whom and expects what in return”. The central
notion of e3 value ontology is the concept of value and the main design decisions represented in an e3 value business model are:
a. Who are the business actors?
b. What offerings are there and who are the actors involved in these offerings?
c. What are the elements of these offerings?
d. What are the value-creating or value-adding activities to produce and
consume these offerings?
e. Who performs them?
The e3 value ontology consists of several key elements (see Figure 4).
They are actors, value objects, value ports, value interfaces, value activities
and value transfers. An actor is an economically independent entity. It is
often, but not necessarily, a legal entity, such as an enterprise or endconsumer. A value object is something that is of economic value for at least
one actor. Examples of value objects are a car, Internet access, or a stream of
music. Actors use value ports to provide or receive resources to or from other actors. It has a direction: in (e.g., receive goods) or out (e.g., make a payment), which indicates whether a resource flows into, or out of the actor. A
value interface is used to group value ports. It shows the objects of value an
actor is willing to exchange as compensation for another object through one
of its value ports; for instance, a reader gets an article from a publisher in
return for a payment. That is a value interface is used in e3 value as a means
of modeling economic reciprocity. A value interface must contain at least
one value port but can have many ports. However, if one port of an interface
is activated, then all other ports in it must also be activated to be able to exchange value objects through that interface. This means that all ports must
exchange value objects or none at all. A value transfer is a pair of value ports
of opposite directions belonging to different actors. It represents one or more
potential trades of resources between the actors. A value activity in e3 value
is an operation that can be carried out in an economically profitable way for
at least one actor.
50
Figure 4. e3 value business model showing the main concepts in the ontology
Three sub-view points: the global actor view; the detailed actor view; and
the value activity view are used in e3 value business models. The global actor
view models all the actors in a network business environment along with the
value objects consumed, created and exchanged by them. Figure 4 shows the
concepts and their relationships of e3 value ontology in the global actor view.
The detailed actor view in e3 value ontology provides the information
such as value constellation and partnerships. It is used to model and it breaks
down an actor identified in the global-actor view into more actors wherever
it is applicable and shows the value that is offered by each other. This means
that in the global-actor view, one can represent a complex situation of having
many actors unite together to provide a certain value object to its environment. In the detailed-actor view this composite actor is decomposed down to
a set of actors showing the partnerships among them and what value objects
are created and offered by them. To support this, they introduce two additional concepts: a composite actor and an elementary actor, both are related
to an actor via a relationship. It should be noted that in the case of a composite actor, it is not the actors which are grouped but the value interfaces belonging to them. This is due to the fact that the customer may not see who
provides what, in the case of a value object, it is a bundled product and one
may only see this bundled product.
Finally, the value activity view represents the assignment of value activities of actors.
The e3 value ontology also facilitates carrying out a profitability analysis
of the business model created based on it and can be seen as an advantage of
the approach.
51
Figure 5. The e3 value ontology (taken from Gordijn et al. 2000)
2.3.1.3 REA ontology
REA ontology proposed by McCarthy (1982) has its roots in accounting
where every transaction is seen as either incrementing or decrementing resources. For example in a purchase, the buyer gives up money in order to
receive goods. In this case while the amount of money that the buyer has is
decreased, the amount of goods he has is increased. In recent years, REA
ontology has been further developed to extend its usability e.g. (UMM,
2007), (ISO/IEC, 2007) as a business modeling ontology.
The basic REA ontology model is depicted in Figure 6:
Figure 6. The basic REA ontology
REA classifies business activities around three main aspects of an exchange:
the resources that are the subject of the exchange; the economic activities
that transfer these resources; and the participating agents. To facilitate binding the main components of the ontology together, REA defines three rules
(Geerts & McCarthy, 2005):
52
1. Axiom 1 – at least one inflow event and one outflow event exist for
each economic resource
2. Axiom 2 – all events effecting an outflow must be eventually paired
in duality relationships with events effecting an inflow and viceversa;
3. Axiom 3 – each exchange needs an instance of both the inside and
the outside subsets.
These axioms aim to define the direction of resource flows, the rules for
coupling reciprocal economic events and the rules for defining the relationship between resource exchanges and the business stakeholders. More precisely, they define the rules that underlie the structuring of core concepts and
their relationships to each other in REA ontology. The intuition behind these
rules is that every transaction can be described in terms of the relationship
between several things: the resources, the events that transfer these resources
and their relationship to each other and the actors involved in these events.
The core concepts in REA are Resource, Events and Agents which are
more often called Economic Resource, Economic Events and Economic
Agents. The economic resources in REA are the things exchanged between
the agents. They are scarce and are under control of an enterprise. Products,
service, and labor are examples of resources. Economic events facilitate the
exchange of these resources between actors. REA defines two types of economic events: increment and decrement events. They mean that to receive a
resource an agent must give up another resource where the event associated
with receiving a resource is an increment event and the event associated with
giving up a resource is a decrement event. For example, to receive a product,
a customer should give up the money he has. The connection between these
two reciprocal economic events is an important economic primitive in REA
and is defined as the duality relationship.
Recent developments of REA (Geerts & McCarthy, 2005) distinguish two
types of events: transfers and transformations. The transfer events are related
to transactions with external actors while transformations are the events related to the value creation of an actor. Stock-flow relationships in REA describe the connection between the economic events and the economic resources. It differentiates among sets of stock-flow relationships related to
transfer and transformation events. In the case of transfer events, the stockflow relationship takes values: give and take. For example the customers
give up cash to take products. Possible stock-flow relationships between
transformation events and the resources are: use, consume and produce. According to (Geerts & McCarthy, 2005), when a resource is used, it either
ceases to exist or leaves its original form so as to be unrecognizable. In contrast, consuming a resource will make it gradually decrease its original form.
In a transformation process a resource is either used or consumed to produce
a resource.
53
Figure 7. Economic event types and their respective relationships (taken from
Geerts & McCarthy, 2005)
In addition to the core concepts mentioned above, REA is also extended
to include various other constructs to model the value chain of a company.
These include concepts such as commitments, contract, schedule and economic claim. Economic commitments in REA represent the planned and
scheduled events for a well-defined future. The actual economic events and
their respective commitments are connected by the executes relationship.
Similar to the duality relationship between pair-wise actual economic events,
REA also defines pair-wise requited commitments having the reciprocal
relationship between them. Economic agreement in REA bundles reciprocal
commitments. Based on the nature of the economic event, REA differentiates two types of agreements: contract and schedule. The transfer events
execute contracts while the transformation events execute schedules.
Later on, the typification of concepts is introduced in REA to abstract
away an actual phenomenon and capture common descriptions applicable to
a group of instances. This concept is important as if an actual phenomenon
no longer exists, the abstract definition in the typification is preserved for
future use. In REA these typification definitions are regarded as the components in the knowledge level while the actual phenomena are in the operational level. There are four main types of images in REA: Economic Resource Type; Commitment Type; Economic Event Type; and Economic
Agent Type. A car is an example of a resource type which applies to a large
number of actual cars at the operational level. An example of an agent type
is a market segment containing preferred customers. In addition to that there
54
can also be typifications of certain other phenomena such as Economic
Agreement, etc.
Recent developments of REA provide facilities to represent workflow and
task specification across value chain, business process and economic event
layers (Geerts & McCarthy, 2005; Gailly & Poels, 2007). Additional conceptual images such as process and task (business events) have been introduced
to represent horizontal and vertical decomposition of activities within and
across the layers. A process in REA represents the exchange of economic
resources between actors and different activities required to realize it. A
typical example of an exchange could be selling (economic event) goods
(resource) for payment (economic event) of cash (resource). The actual realization of this could include a number of smaller activities and these are
called tasks (business events). For instance, assessing customer needs,
checking whether the goods are available and choosing the goods that match
the customer requirements, etc. could be different tasks required to execute
the exchange: selling goods – receiving payment.
2.4 Frameworks for modeling business collaborations
In the previous sections we presented three well-established business modeling ontologies. In this section we discuss international initiatives based on
REA ontology to further facilitate business as well as process modeling. As
an example, UN/CEFACT Modeling Methodology (UMM) (2003) and
OeBTO (ISO/IEC, 2007), are two such initiatives aimed at developing a
more comprehensive methodology for enterprise modeling. Both the UMM
and OeBTO have their roots in REA ontology. In each of them, REA concepts have been extended to support reusability of process and information
descriptions. From a business collaboration point of view, these frameworks
are aimed at standardizing business related knowledge representation without regarding to the underlying implementation technology. Compared to
business modeling approaches described above, the main focus of UMM is
to capture information regarding the business processes and to provide a
comprehensive process analysis methodology. The purpose of the OeBTO is
to bring about different concepts in different standardization efforts into one
umbrella and create a formal framework for defining the composition of
business collaborations between actors.
2.4.1 Business collaborations and business transactions
Generally, business collaborations represent trading between two parties,
namely the “seller” and the “buyer”. In business collaboration, a seller and a
buyer are involved in activities that enable a flow of resources between
them. A simple business collaboration should at least consist of two resource
55
flows between seller and buyer. When a time dimension is added to describe
a business collaboration, these two basic events can be defined as: an event
initiating a flow of resources and an event responding to that. That is, at a
very basic level, in a collaborative environment there should at least be an
initiating resource flow and a responding resource flow. Open-edi (ISO/IEC,
2007) defines that the business activities of collaborative space, where transfers of resources occur between actors, should be viewed from an independent viewpoint and not from the perspective involving any business partner.
Figure 8 depicts business collaboration space activities between a buyer and
seller.
Figure 8. Collaboration space (taken from ISO/IEC, 2007)
The exchange of resources in the collaboration space provides the basis
for defining business transaction. Business transactions are often used as a
means to group reciprocal resource transfers between actors. A typical example of a transaction could be exchanging goods for cash.
Different business modeling approaches model business transactions in
different ways. For instance, e3 value uses the notion of value transaction to
model a business transaction where it represents a set of requiting value
transfers between different actors. Though, initial versions of REA ontology
do not define the notion of business transaction, the extended versions of the
ontology, such as OeBTO, include the concept of business transaction. In
contrast to the e3 value definition of a value transaction, a business transaction in the OeBTO is defined as an economic exchange occasioned between
two independent parties where each party reciprocates with a value desirable
to the other party. One of the main reasons for the difference between two
definitions is the influence of their respective ontological basis for defining
reciprocity. The OeBTO uses REA ontology as its basis and the reciprocity
in REA ontology is modeled by the duality relationship between two economic events. Therefore the collaboration space in REA primarily consists
of reciprocal events happening between two actors. However, the activities
responsible for exchanging resources between actors are represented in e3
value ontology by using value transfers. Though value transfers are more or
less similar to economic events in REA, the difference between them is that
56
in e3 value ontology, a value transfer is used as a means to interconnect two
actors and the reciprocity between value transfers are modeled by means of
using value interfaces. Thus e3 value gives freedom to couple more than two
value transfers to model the reciprocity.
In contrast to the OeBTO definition of a business transaction, the Openedi framework in (ISO/IEC, 2002) defines a business transaction in a more
general way. There it is defined as a pre-defined set of activities initiated by
an organization to achieve shared business goals and terminated upon the
achievement of previously agreed conditions with other collaborating organizations. From a number of actors who could be involved in a business transaction, this definition is more or less equivalent to the e3 value definition of
value transaction. Therefore, a common basis for defining a business transaction could be that it encompasses resource transfers for fulfilling a particular commitment between collaborating actors.
Often business transactions are analyzed considering business and IT aspects. For instance, Open-edi frameworks in (ISO/IEC, 2002), (ISO/IEC,
2007) and UMM (UN/CEFACT, 2007) provide methodologies for analyzing and modeling business transactions based on Open-edi reference ontology which considers both business and IT aspects of business transactions. In
the business aspect, exchange of commitments among parties involved in the
business transaction are considered whereas in the IT aspect exchange of
data among their IT systems are considered. Moreover, the Open-edi framework in ISO/IEC 15944-1 (ISO/IEC, 2002) identifies Person, Process and
Data as key elements in a business transaction. A person can be individuals
or any legal entity such as organizations which can make and fulfill commitments. The process element represents a series of actions performed by
persons in a defined manner to achieve expected results. Finally, the data
component of a transaction refers to the exchange of information between
collaborating actors. The Open-edi framework also clarifies that, though
information can be available in different forms, electronic business transactions require information (data) which can be stored and retrieved by computer systems.
2.4.2 Fundamental activities of a business transaction
Actors involved in a business collaboration perform activities, for example
to recognize their needs, establish a link between them and agree on terms
and conditions of the exchanges, and finally exchange objects of value between them and fulfill the previously established commitments. The Openedi framework in (ISO/IEC, 2002) for analyzing operational aspects of a
business transaction defines that the activities performed in a business transaction span over five distinct phases: planning, identification, negotiation,
actualization and post-actualization. Below, we briefly discuss the five phases of an Open-edi business transaction.
57
Planning: In the planning phase, the customer and the provider are engaged
in activities to identify the actions needed for selling or purchasing goods
and services. More precisely, the provider engages in activities related to
publishing data pertaining to the availability of goods and services. As an
example, a distributor publishes catalogues. In the planning phase, the customer engages in activities such as searching for potential suppliers, requesting additional information regarding goods and services from the potential
providers, etc.
Identification: The identification phase involves the activities needed to
exchange information among providers and potential customers regarding
selling or purchasing goods and services. These information bundles regard
more detailed data required to progress from the planning phase to the negotiation phase. For example, a provider sends a quotation, which contains
detailed specification of goods, services and conditions, to a customer. The
primary aim of the identification phase is to build a link between potential
buyers and sellers so that a level of trust can be established between them in
order to exchange more detailed information that both of them were not be
willing to exchange without proper identification in the planning phase. For
example, a seller may require more detailed information about the buyer,
whether the buyer is an individual or an organization, to determine the level
of external constrains that may be applied.
Negotiation: In the negotiation phase the buyer and seller engage in activities leading to an agreement on the detailed specification of goods or services that are to be exchanged and the conditions under which the exchange of
goods may take place. That is, the process of negotiation is directed at the
formation of a formal contract which specifies the terms and conditions associated with the business transaction. Furthermore, at the end of the negotiation phase, the buyer and seller agree on the involvement of third parties in
the transaction and exchange rights such as complete ownership rights, short
term licenses to use, etc. Information regarding the post sale services are also
specified and agreed during the negotiation phase.
Actualization: Activities necessary for the execution of results agreed between the collaborating parties take place in the actualization phase. The
seller starts executing activities necessary for transferring goods and/or services to the buyer as agreed in the negotiation phase. At the end of the actualization phase, the seller completes delivering goods, and/or services, rights
to the buyer. The buyer in response reciprocates with an acceptable equivalent value to the seller as agreed in the negotiation phase.
58
Post-actualization: In the post-actualization phase, the buyer and the seller
engage in activities and associated information exchanges that are deemed
necessary to occur after the agreed upon good and/or services are exchanged.
These activities can include invocation of warranty coverage, after sale services such as product recalls, fixing up defects, complaint handling, long
term payment handling, etc.
The Open-edi framework suggests that the fundamental activities discussed above may take place in any order, for example, post-actualization
aspects such as information regarding warranties of the goods or services
may be made available in connection with the planning phase activities. Further, collaborating parties may terminate a collaboration based on some
agreed method without going through all the distinct phases. For instance,
the collaboration between a supplier and a customer may come to an end at
the end of the identification phase where a customer decides that the detailed
specification of goods does not fit with his needs. Though the phases comprise of distinct activities, they can be completed in a single continues interactive dialogue or in several discrete dialogues between the collaborating
parties.
2.5 Service-oriented modeling
It was highlighted in the previous sections that the goal and business modeling are used to describe a high level view of stakeholder intentions, business
strategies and business activities within and between organizations. Lately,
service-oriented modeling is recognized as an important aspect in provisioning e-business solutions. A primary aim of the service orientation is to hide
complex and heterogeneous technical details from users by providing a standard way to communicate with business applications. Such technological
independence allows services offered by different systems used in a flexible
manner thus allowing flexible collaborations between them.
In this section, we first discuss different categories of service orientation,
for example, business and software orientation and how service is defined in
these different contexts. Then we conclude the section by giving an overview of business-oriented e-service design.
From a business point of view, a business service represents a service in
general, for instance, selling goods. In an information systems context, it is
generally a concept that abstracts away specific technical details of a business process allowing it to be reused in many other business processes. A
software service is a special kind of service where a service is associated
with a software application. However, different authors define them in different ways. In the following we list definitions from various sources and
analyze them. This kind of analysis will help to identify the most basic com-
59
ponents attached to services notion in these contexts and to identify relationships among them.
W3C: "A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view
of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL)." (W3C, 2004).
OASIS: "A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." (OASIS, 2006).
WSMO: "A service in contrast is the actual value provided by this invocation. Thereby a Web service might provide different services, such as for
example Amazon can be used for acquiring books as well as to find out an
ISBN number of a book. A WSMO Web service is a computational entity
which is able (by invocation) to achieve a users goal." (Roman et al., 2005).
Preist: "A service is the provision of something of value, in the context of
some domain of application, by one party to another. We need to distinguish
between a particular provision of value from the general capability to provide. We refer to the former as a concrete service, and the latter as an abstract service. Hence an abstract service is defined as the capacity to perform
something of value, in the context of some domain of application. An agreed
service is an abstract service agreed between two parties." (Preist, 2004).
UN: "Services are heterogeneous outputs produced to order and typically
consist of changes in the conditions of the consuming units realized by the
activities of producers at the demand of the consumers." (UN, 2002).
The most common view of a service among the sources listed above is
that a service is an abstract thing and once it is invoked will achieve user
goal(s). However the exact way of defining the service depends on the perspective of a particular source, for example, W3C and WSMO focus on Web
services (or software) perspective while others, for example, Preist, UN,
OASIS, etc. focus on business services perspective in general.
In the business service perspective, a service is defined by aligning it with
the value it creates to users or seeing it as a way of giving them an access to
business processes. It hides away the actual implementation details of a
business process and gives a common access window. Therefore, a service in
here is a concept on the knowledge level. A service also has a provider and a
user, which are also knowledge level concepts (Preist, 2004; W3C, 2004).
Defining a service as an abstract knowledge level concept gives providers
the flexibility of implementing it in different ways in order to offer it to ser60
vice users. Preist describes this as distinguishing between a particular provisioning of service from the general ability to provide it.
When a service is offered by a particular agent to a particular user (customer), the actual number and types of resources used in the implementation
of the service and the way of offering it, can be different. In realizing a service, a particular provider may perform various tasks and produce something
of value to service users (UN, 2008; Preist, 2004). For example, in a hair
cutting service, hair cutting could be done in different ways by using different resources.
The service realization is done with a goal of meeting certain demands of
service users (UN, 2008). For example, a particular user may want to get a
haircut in a short time so that the provider may use machines instead of scissors and may also skip tasks like shampooing, etc. to meet his customers
timing constraints. The service realization and provisioning are also done in
compliance with the business policies and constraints of the provider organization (OASIS, 2006).
E-service is another notion that is used in service-related literature. Eservice is defined as the offering of a business service by Internet or any
other electronic means such as Automated Teller Machines (ATMs), wireless networks, etc. Web services technology platforms are often used to realize e-services. According to Baida et al. (2005), a distinction between business service and e-service is that, a business service represents a computationally ill-defined value-oriented activity and an e-service represents a welldefined concept with concrete tasks that together realize the broadly defined
value-oriented activity view of a business service by thus making it suitable
for an online activity.
A Web service in above is defined in two ways. In (W3C, 2004), a Web
service is defined as a special kind of a business service where a software
application(s) is involved. In (Roman et al., 2005), a Web service can provide more than one services and hence for them the Web service seems more
general than the service, for example, Amazon can be used for acquiring
books as well as to find out an ISBN number of a book and for them these
are distinct services provisioned by a single Web service. Considering the
above example, it we can reasonably argue that service in (Roman et al.,
2005) refers to both business and e-services.
These two definitions unveil an important aspect of a service, its compositeness. That is a service may consist of more than one service that will
fully realize the first service when it is invoked. This means that, regardless
of whether a service is either a general business service or a Web service, it
could be a container of several other services that fully realizes the goals of
that service. This further illustrates the nature of abstractness which also
applies to Web services as well. When an abstract service, either Web or a
general business service is invoked, it may be realized through several other
services which could either be Web or general business services. In addition
61
to the compositeness, Web services also inherit characteristics of services
such as having provider and user agents, abstractness, realization through
several tasks, etc. (W3C, 2004).
Based on different characteristics of services that we discussed above, in
the following, we summarize our view of a service. By service, here we
mean both business and e-service.
• Services are abstract resources with well-defined common access interfaces.
• A service is always attached to a provider agent and a user agent. The
former may or may not be the owner of the service but could be something or someone who can perform tasks that realize the service.
• A provider may realize a service by performing various tasks that
creates some value to service users.
• The abstract nature of a service provides the flexibility to realize it in
different ways by using different resource types as required by the
service itself and also meeting the goals and needs of both the organization and the service users.
• The realization of a service may be carried out according to the policies and constraints of both the organization and the customer
• A service can be composite meaning that it requires one or more other
services to be executed in order to fulfill the goals of that service.
2.6 Related work on business-oriented e-service design
Having discussed general background related to goal modeling, business
modeling and service design, in this section we discuss related works on
business-oriented service exploration and realization.
From a business point of view, the realization of a service is defined by
the description of the business process underneath the service. Therefore, it
is evident that the designing and development of e-services encompass technical as well as business aspects. As such, it is important to identify right
portfolio of e-services which are aligned with the business strategies of a
company and integrate them together with activities of the company’s value
chain.
Integration between business and information systems has been identified
as a significant problem and has been comprehensively studied over recent
years. As such, there have been upsurge in number of research studies that
focus on business-oriented exploration of e-services; examples are (Papazoglou & Heuvel, 2006; Levi & Arsanjani, 2002; Zlatev et al., 2004; Arsanjani et al., 2008; Gordijn et al., 2006a; Gordijn et al., 2009), (Andersson et
al., 2008). In general all these approaches focus on assuring that the right set
of e-services are identified using a top-down approach. That is, the methods
start with a high-level business analysis to identify e-services that may even62
tually be realized by, different technologies such as Web services technology. Closer analysis of these approaches shows that, they use goal, process
and business models as points of departure for identifying e-services.
Often, the relationship between high-level business goals and technical
architecture in software projects, differ (Levi & Arsanjani, 2002). In order to
integrate technology and e-services that fulfill these business goals, a number of studies propose using business processes as a point of departure (Levi
& Arsanjani, 2002; Papazoglou & Heuvel, 2006; Arsanjani et al., 2008).
The approach proposed in Service-Oriented Modeling and Architecture
(SOMA) by IBM focuses on the top-down analysis of business domains to
identify their constituent business processes as a part of their method for
designing e-services and aligning them with existing systems (Arsanjani et
al., 2008). The proposal does not provide explicit information about how
business models are used in the e-service design but it identifies the importance of business modeling as a part of identifying the focal area that the
service-oriented solution is required (Arsanjani et al., 2008). Further, the
approach uses a goals hierarchy for the gradual decomposition of business
strategies down to a set of actionable business goals from which e-services
that fulfill business strategies are identified.
The e-services identification approach (Papazoglou & Heuvel, 2006) focuses on a process-oriented framework for the identification of e-services
and their relationships. It emphasizes the importance of aligning technical
aspects of e-service design to business environment during planning, and
analysis and design phases of e-service design and development life cycle.
However, the approach is primarily focused on the business process aspect
of the business environment as a means to identify e-services. As such, it is
not clear how the alignment of e-services to business strategies is done
which is what we do in this thesis.
The approaches proposed in (Gordijn et al., 2006a; Gordijn et al., 2009;
Andersson et al., 2008; Zlatev et al., 2004, Baida et al., 2005) use needs,
goals and business models as the point of departure. The general argument is
that customer needs, goals and business models offer a solid platform for
justifying the choice of e-services and give a precise understanding of the
environment in which the e-services will function. In particular, the approaches mentioned above suggest that the service-oriented requirements
engineering should begin with identifying goals of different actors and designing a goal-aligned business model. Additionally, some of them provide a
means to quantitatively analyze business processes and IT resources required
to implement them as e-services and evaluate profitability of them (Gordijn
et al., 2006a; Gordijn et al., 2009).
In Gordijn and Petit (2006a), the authors discuss the relationship between
goal and business models as a foundation for the identification of goal
aligned and economically sustainable business services. Nevertheless, their
approach does not propose a method for relating goals with business model
63
components and e-services; issues that we address in this thesis. Also, the
approach proposed in Baida et al. (2005), uses ontologically founded method
for describing consumer needs to elicit resources and map them to eservices. However, the proposal does not relate the services to a business
model which is an important aspect that we consider in our work.
The e-services identification and realization approach presented in Gordijn et al. (2009) suggests that three viewpoints: value, process, and information systems, should be considered in service-oriented requirements engineering. In the value viewpoint, three types of descriptions of e-services are
produced. Firstly, top-level customer needs are identified and mapped them
to e-services to be offered by various business actors. Secondly, activities
related to the creation of these e-services are modeled. Finally, the profitability of the proposed e-services is evaluated. In the process view, interorganizational business processes are identified considering all the actors
involved in the business case. These business processes are then examined
and tasks performed by individual actors are identified and modeled using
Unified Modeling Language (UML) activity diagrams showing the orchestration of tasks. Finally, in the information systems viewpoint Web services
specification standards such as Web Services Description Language
(WSDL) (Christensen, Curbera, Meredith & Weerawarana, 2001) and Web
Services Business Process Execution Language (WS-BPEL) (OASIS, 2007)
are used to describe the business processes. To obtain the information system viewpoint, the approach uses the UML Profile for Automated Business
Process developed by IBM (Amsden, Gardner, Griffin & Iyengar, 2003).
However, even being model-oriented, the approach does not define business
and system-oriented models and model transformation as recommended by
MDA discipline. Besides, even being primarily goal-oriented, the approach
does not utilize goal modeling as a technique to assist systematic modeling
of a business and also focuses on the consumer perspective, that is the goals
of consumers.
2.7 Running business scenarios
In this thesis, we use two business scenarios from different domains to demonstrate the utilitarian value of the created artifacts. These two business scenarios; Massively Multiplayer Online Games (MMOG) from the online gaming domain and the eye-care health case (Henkel et al., 2007) from the
healthcare domain are discussed in detail below.
2.7.1 Massively Multiplayer Online Games (MMOG) case
In this business scenario there are three actors and market segments involved: the Game Provider, the Internet Service Provider (ISP) and the
64
Game Player. The Game Provider is responsible for producing the game
content and selling and distributing its software on CDs (CD delivery) to the
Game Players. In order to play the game, the Customers need Internet
access, which they get from the ISP by paying a fee (Payment). They also
need access to the game server (Game access), which they get from the
Game Provider. The Game Player obtains both Games access and CD delivery by paying a fee (Payment) to the Game Provider. In order to provide
game access to the Game Player, the Game Provider gets Hosting service
from the ISP in return for a fee (Payment). The simple business model in the
figure below depicts the MMOG business case explained above. Actors are
shown by straw man, resource transfers by arrows between actors with the
names of resources as labels.
Figure 9. An e3 value business model for the MMOG case
2.7.2 Eye-care health case
Figure 10 depicts a simple business model of the eye-healthcare case. The
model is an excerpt of a larger case defined in the REMS project (Henkel et
al., 2007) that will be used as a running example throughout this thesis.
The model depicts the resource transfers (by arrows between actors) taking
place between three actors: a Patient, a Primary care physician and a
Healthcare specialist (represented by straw man). Having a problem with
her eye(s), the patient contacts the local primary care physician, to get an
opinion and treatment. If necessary, the primary care physician refers the
patient to an eye specialist clinic. The resources, that the patient gets, are the
treatment including a diagnosis in return for a fee ($). If primary care decides that the patient needs further treatment, they will refer the patient to the
65
healthcare specialist. When the patient is referred to the healthcare specialist,
the primary care offers a referral to the healthcare specialist. The patient
visits the healthcare specialist and receives advance treatment in return for a
fee ($).
Figure 10. Major actors and their relationships in the eye-care case
66
3 Analyzing Resources, Resource Transfers
and Conversion Activities
3.1 Introduction
In this chapter, we set the basis for designing business models by analyzing
the notions; resource, resource transfers and conversion activities used in
business modeling. The results of the analysis are used as a part of developing the business modeling and service designing methods presented in forthcoming chapters.
Resource, resource transfers and conversion activities are fundamental
notions of business modeling. Different business modeling approaches use
different naming conventions to denote the resources and resource transfers.
For instance, e3 value business modeling ontology uses the notion of value
object to represent a resource, value transfer and value activity to denote
resource transfers and conversion activities. The REA ontology uses the
notions economic resource, economic event and conversion event to denote
resource, resource transfer and conversion activities respectively. A resource, in both these business modeling ontologies, is something that has a
value and that can also be transferred from one actor to another. However, a
value object in e3 value represents a more general notion of a resource and
accommodates things such as consumer experience, in addition to goods,
services and money which are often defined as resources in other business
modeling approaches such as REA and BMO. From a broader perspective,
what is perceived as a value by a consumer may include more than conventional resources such as goods, money, services. Value may lie in a resource
as well as in the way it is offered to him. For instance, when a customer buys
a book (resource) from Amazon.com, the book itself and the way it is offered such as one-click shopping may produce value to the customers. While
the book may give him an opportunity, for instance, to increase his knowledge, one-click shopping may create him value by saving his time required
to buy the book.
From a value point of view, a single resource transfer may include a transfer of different components that delivers some value to a consumer. For instance, consider an offering of a movie by a cinema. While the movie is the
67
resource of primary concern (or simply, core resource), the cinema may also
offer tickets to customers to use as tokens of the right to see the movie.
However, they are often modeled in business models as a single resource
transfer activity considering the movie as the resource. Yet, clearly, movie
and ticket are different but interrelated things of value that are offered by
cinema to its customers. They may carry different values and therefore it is
important to represent them in a business model. Such an elaboration of resource transfers will make a business model a better platform to design other
types of models such as process models and to design e-services.
In contrast to resource transfers, conversion activities are mainly responsible for producing resources. They represent internal activities of an actor
that creates resource to be either used by another conversion activity or
transferred to another actor by a resource transfer activity.
3.2 Resources
Typically, customers rate objects of value based on their fitness to achieve
the goals of buying them. Here, objects could be products like books, cars, or
even typical services like haircuts, and medical treatments. The, value
created by these objects can be of a more psychological and social nature,
such as beauty, pleasure, health state, honor, and the feeling of safety. Furthermore, Gordijn (2002) also recognizes consumer experience as having a
value. To distinguish the objects of value mentioned above from value
created by them, we call the former economic resource.
Economic resources
An economic resource is a resource that can be under the control of an actor,
in the meaning that the actor may have legal rights on the resource. That is
an economic resource is an object that can be offered by one actor to another. They can be physical products like cars and refrigerators, or can also be
services such as haircuts and medical treatments. Economic resources have
utilitarian value to consumers. Therefore, they can also fit the extrinsic value
category in Holbrook’s classification of consumer values (1999).
However, there is no very precise agreement of what an economic resource could be. In REA ontology, the concept is called economic resource
and is defined as something of value under control some actor. In e3 value,
the notion value object is used to represent an economic resource. A value
object in e3 value is defined as some object of value to at least one of the
collaborating actors. Generally, goods and services are identified as economic resources (Gordijn, 2002; McCarthy, 1982). Physical objects such as cars
and books are examples of goods whereas things such as transportation,
haircuts, and eye treatments are examples of services. In addition to goods
and services, rights are also identified as an economic resource that has a
68
value to the receiving actor (Weigand et al., 2006; ISO/IEC, 2007). In addition to that information is also treated as an economic resource (Henkel et
al., 2007; Ilayperuma & Zdravkovic, 2009). For instance, data in certain
contexts such as referrals in the healthcare sector and customer profile information can be regarded as information goods.
The Open-edi framework in (ISO/IEC, 2007) presents a structured list of
possible economic resource types and subtypes. The Open-edi categorization
of economic resource includes three primary types: goods, services and
rights (see Figure 11). Goods are tangible resources such as capital assets
(e.g. vehicles), raw materials and natural resources (e.g. steel and petroleum)
and monetary resources (e.g. money), etc. Services represent abstract value
adding activities offered by a provider to consumer. Typical examples of
services are consultancy, transportation, treatments, etc. Rights are intangible resources and can be exchanged between actors as economic resources.
Among the above mentioned economic resources rights can play a dual
role. They are always attached to some other object such as a car, real estate
or even information goods in a tangible form such as books, songs. In some
cases it is meaningful to discuss rights as resources of their own. A typical
example could be music rights. In this case, though the right is attached to a
specific object, a piece of music, it is sold as an economic resource.
Rights also specify what the possessor of them is eligible to do. For instance, a person who rents a car has a limited use right during the period he
has access to it. In contrast to a situation where he owns the car, the things
he is eligible to do are bound by the agreement between him and the renting
actor.
Figure 11. Resource types and possible sub-types (taken from ISO/IEC, 2007)
As a fundament for analyzing economic resources in this thesis, we utilize
the following categories:
• Goods, which are physical objects, like cars, refrigerators, and cell
phones.
• Information, which is data in a certain context, like blueprints, referrals,
and customer databases.
69
•
Services, which are economic resources that encapsulate other resources, and are used to increase the value of some other resource. Examples of services are haircuts and eye treatments.
• Rights, which describe the activities that the resource-holder can perform. For example, buying a book does not transfer the right to the buyer to reprint it and sell. For that the buyer may need to obtain the economic resource “copyright”.
• Money, which is a media for exchange without any restriction on economic resources and actors.
For simplicity, in the rest of the thesis, we use the term resource to denote
economic resource discussed above.
3.3 Resource transfers
The business model ontologies presented in the previous chapter, identify
and define different types of business events with respect to the role that they
play in creating and transferring different resources within and between actors. For instance, activity in BMO is defined as actions performed by a
company in its value creation, marketing and profit-generating process. It
includes internal value creation activities of an actor as well as activities
needed to transfer objects of value to its customers. An economic event in
REA represents an activity that transfers an economic resource from one
agent to another. REA economic events primarily aim to model external
resource transferring activities. In contrast to BMO and REA, e3 value distinguishes between the activities that create value and the activities that
transfer these resources between the business stakeholders. The internal value creating activities in e3 value are represented by value activities as the
resource transferring activities represented by the value transfer activities. In
the business and service designing methods in this thesis, we primarily use
the notion of resource transfer to represent the transfer of an economic resource between actors.
Different components of a resource transfer
A resource transfer is defined as an activity that transfers a resource between the trading parties. We identify that every resource transfer that happens between two actors, for instance A and B, should include at least one or
more of the following:
1. transfer of right from A to B;
2. transfer of custody (enabling access to the resource) to B;
3. evidence documents from A to B.
Transfer of right means that the provider gives away his right to a resource (to obtain the right to a different resource: e.g., money). In a resource
transfer, the transfer of right is not enough and the buyer should be enabled
70
access to the resource. Enabling access to a resource is important as otherwise a buyer would not be able to exercise his right on it.
In a resource transfer, a customer may also be given documentary evidence. The documentary evidence is optional in a resource transfer but could
be useful in cases where there are post-actualization activities such as damage distribution and/or cases where there is an assessment of partial fulfillment of commitments. An evidence document can play different roles in a
resource transfer (Gordijn, Petit & Wieringa, 2006b). It can be used as a
token of a right to transfer and is useful in obtaining the access to exercise
the right. For example when one buys a movie ticket, the cinema transfers
the right to see a movie to the buyer. The movie ticket is the evidence that
the buyer has the right to see a movie. Here, it plays the role of an evidence
document for the right transfer. When a buyer wants to watch the movie, he
hands over the ticket to the cinema and gains access to the movie. In this
case, he does not transfer anything new to the cinema but uses the ticket as
an evidence document to obtain access to the movie.
3.4 Conversion activities
Conversion activity changes some features of a resource thereby either increasing or decreasing a resource’s value. They represent the activities internal to an actor. Typically, a conversion activity answers the following questions:
1. What are the activities carried out by an actor and with the use of
what resources?
2. What resources are produced?
3. What features of the resources are changed?
If the conversion activity produces a new resource or change of feature(s)
of an input resource to increase its value, it is called a produce activity. If the
input resources cease to exist after the conversion event, it is a consume activity and if they exist after the conversion event then it is a use activity.
Among them, the produce activity is an increment activity and the use and
consume events are decrement activities.
3.5 Summary
Resources and activities that transfer and produce them are important notions in business modeling. Different business modeling methods use different notions to represent them.
In business modeling, a common understanding of a resource is that, it is
something that has a value and that can be transferred between actors. In our
work, we call this: economic resource (or resource). We identify, goods,
71
services, rights, information and money and voucher as a classification of
economic resources. In addition to these economic resources, internal values
play an important part in business modeling. Internal values can be defined
as some property such as beauty, health state attached to an actor or properties attached to facilitating services such as delivery of an economic resource. An example could be convenience attached to home delivery. These
internal values are often regarded as success factors that facilitate a firm’s
value proposition and distinguish the firm from its competitors. To use them
in business modeling, we suggest a tentative list of internal values and discuss their possible relationships to planning, identification, negotiation, actualization, and post-actualization phases of a business transaction.
A resource transfer transfers economic resource between actors. A resource transfer is often modeled as a single component without referring to
different aspects of it such as giving away of control of a resource either
temporarily or permanently and giving access to it to a buyer. In this thesis,
we represent these aspects by identifying three components of a resource
transfer: right transfer, custody transfer and evidence document. While the
right transfer is always included in a resource transfer, the latter two components are optional. For instance, when buying a piece of land, typically, the
buyer is given right to the land. It may also include a legal document such as
the deed of the land which could be considered as the evidence document.
Clearly, the custody transfer does not typically happen in this case. Furthermore, both custody and evidence document transfer may sometimes be trivial so that they are not explicitly modeled.
72
4 Designing Business Models Based on Goal
Models
4.1 Introduction
Goal models are used to capture vital information in different stages of business and information systems design. They primarily help in explaining the
interests and intentions of actors and relationships between them. Thus, goal
models also play an important role in defining business strategy of an organization.
Goal modeling techniques are often used in requirements elicitation and
requirements specification in a systems development life cycle. For instance,
goal modeling techniques such as i* (Yu, 1995) and BMM (2007) are used
in requirements elicitation to represent different interests of actors, opportunities and barriers to achieve them. In the requirements specification, goal
modeling techniques such as KAOS (Dardenne et al., 1993) provides a
means to represent relationships between elicited requirements and desired
system functions. Regardless of which phase in systems development life
cycle goal modeling techniques are used, they are aimed at facilitating traceability of design decisions. That is they try to answer, for instance why a
certain requirement is modeled.
On the other hand business models aim to model different business stakeholders, activities performed by them and resources or values they offer to
each other. That is business models aim to model the what of the business in
a more abstract way. The design decisions made by a business modeler are
often based on experience. In the business management context, a business
model provides a means for modeling the way business orchestrates its internal as well as external activities in a more abstract way and to identify any
need for changes to survive in a competitive business environment. In the
information systems development context, it provides a means for communicating technical level design decisions to business users. In both these contexts, to make the process of understanding more effective, there is still a
need for linking business model components to the interests of business users. This helps business users better understand the design decisions thereby
helping them to negotiate better design decisions. For business modelers or
73
system analysts, this could provide a methodology for the systematic derivation of business model components and system functions.
In this chapter, we discuss a method for designing goal-aligned business
models. Figure 12 depicts the overview of the method proposed in this chapter. The method consists of two main steps where in step one a goal model is
created. We utilize the goal modeling approach – BMM – for designing the
goal model in this step. A set of templates for formulating means will be
used to design the goal model. In the second step, the goal-aligned business
model will be created. Transformation rules, which define possible actions
associated with each means template, will be used as a means for identifying
business model components.
Figure 12. Overview of the method for designing goal-aligned business models
4.2 Relating goal and business contexts
Relating goal and business has been identified as an important issue in requirements engineering. A number of studies have focused on aligning the
strategic goals of business stakeholders and business activities as an integral
part of designing e-business solutions, for instance, business-aligned e74
services. Among them, (Gordijn et al., 2006b) explore the use of strategic
goals for modeling value constellations. They suggest identifying goals of an
actor based on the Holbrook classification of consumer value (Holbrook,
1999) and then to design a business model that satisfies the identified goals.
The methodology uses the goal modeling technique i* (Yu, 1995) for modeling goals and the business modeling methodology e3 value to operationalize
them. However, the method does not facilitate formulating goals and means
in terms of business modeling notions. Nor does it explain how the goal
model can be used to derive components of the business model. Zlatev et al.
(2004) discuss a goal-oriented approach for designing business models as a
part of designing e-services. The approach discusses developing a goal tree
that represents the goals of the business and designing a business model
from a set of existing business model patterns that are aligned with goals in
the goal tree. To align business strategies to business models (Weigand et al.,
2007) takes a different approach from the sources mentioned above. They
argue that a business model could be better aligned with the goals of an actor
by analyzing rationale behind them in three perspectives: customer, capability and competitor perspectives. They are primarily focused on identifying
different value creation strategies from these three perspectives and how
these strategies can be represented by means of designing different types of
models that show the relationship between the identified values and business
activities of respective actors. Taking a similar line of argument, Pijpers et
al. (2008) highlight the importance of aligning business strategy with the
value creation process in order to align business strategy with information
systems. They suggest that the process of alignment may consider some or
all of four perspectives: business strategy, value creation, business process
and information systems depending on their relevance to the business context under consideration. Nevertheless, the business strategy in this approach
is limited to consider how other organizations influence the business strategy
of the organization under consideration.
Naturally, the business strategies of an organization are influenced by the
goals of its business stakeholders. However, if the goals are not properly
expressed and documented, it makes it hard to clear out business strategies
that outline the business activities and carried out by business stakeholders to
create and deliver value to each other. Therefore, clear expression of goals is
an integral part of drawing out business strategies that define different types
of activities and relationships between the business stakeholders. The overall
goals of a company can remain stable over a long period of time while actual
strategies and activities may change over time and therefore the separation of
general business concerns from specific business activities should be done
(Andersson et al., 2008). This, they argue, would help to focus on different
layers and making more stable models. In this chapter we focus on goal and
business layers and aligning them to each other.
75
Kavakli and Loucopoulos (1999) argue that, when modeling enterprise
knowledge, it is important to understand the current situation of an enterprise, where it wants to position itself in the future and its plans to transform
the enterprise from its current situation to an expected future situation. Considering these aspects, they introduce a framework for developing and documenting enterprise knowledge, called the EKD framework (see Figure 13).
Figure 13. EKD framework for modeling knowledge (taken from Kavakli & Loucopoulos, 1999)
The EKD framework in the Figure 13 shows requirements engineering as
modeling activities ranging from the current situation to an expected future
state. Different states in the figure concern four different modeling aspects.
They are: modeling current state or more precisely the As-Is state, modeling
stakeholder goals with respect to expected changes and alternatives for
changing as-is state, developing a To-Be model by mapping of change requirements to expected future state, and finally defining an evaluation criteria and evaluating the extent to which the stakeholders expectations are met.
Though the EKD framework primarily concerns modeling enterprise knowledge and goals, it highlights the importance of separating different modeling
aspects so that the models can be easily managed and systematically linked
to each other.
4.3 Modeling goals
The difficulty of finding the correct level of abstraction in formulating goals
is a common problem in goal modeling and often, goal models become unfocused since the formulation of goals can range from broad value proposi-
76
tions to specific strategic actions to get a competitive business position
(Weigand et al., 2007). They further argue that the unformalized relationship
between goal and business models acts as a barrier in aligning them. As
mentioned previously, goal modeling techniques are used to achieve different purposes in GORE. Goal modeling techniques such as i* and BMM are
used in business analysis to model business goals specifying relationships
between them.
Among these goal modeling techniques, i* focuses on modeling strategic
dependencies between the business stakeholders, their goals, tasks and associated resources. In general, i* models the intentions of business stakeholders. It explores various dependencies among them and suggests various configuration options to achieve their goals in a collaborative environment. It
consists of two main modeling components: the SD model and the SR model. The SD model focuses on describing dependencies among actors in a
business context while the SR model describes interests of business stakeholders and different configuration options of the business context. Principal
notions of i* includes actor, goal, soft-goal, task, resource and dependency
links, goal dependencies, task-decomposition and means-end. These dependency links specify the kinds of relationships between depender actor and
dependee actor, actions to accomplish intentions of actors and why a certain
task is performed by an actor.
The BMM (2007), concerns identifying motivating factors behind business activities and defining the relationships between them. The concepts in
the technique are grouped around three primary concepts: Ends, Means and
Influencers. They describe intentions of business stakeholders and the environmental factors that influence the possible achievement of these intentions.
Below, we discuss these three concepts in brief.
• End: An End defines something that business seeks to accomplish without indicating how it will be achieved. For instance, an End could be
some broad picture of the future state of the enterprise such as vision or it
could be a more concrete state or condition the enterprise wants to
achieve or sustain such as goals or objectives. A goal in BMM is a statement about a state or condition of the enterprise that it wishes to achieve.
A typical goal of a car renting company could be: “to be the leading rental service provider”. In contrast to a goal, an objective is a time target
and measurable statement.
• Means: A Means on the other hand represents different business capabilities and instruments that can be used to achieve Ends. BMM arranges
means in two forms: Course of Action and Directives. In general Course
of Action describes how to achieve goals and objectives. For instance,
course of action to achieve the goal “to be leading rental service provider” could be “encourage rental extensions”. In addition to defining actions to achieve Ends, Means also define business rules or policies or
77
more precisely directives that govern the execution of the course of actions to achieve Ends.
• Influencers: An Influencer is anything that may affect achieving the
goals. Influencers can be internal factors such as resource related issues,
traditions or habits of the enterprise, or even be infrastructure related issues. They can well be external influencers such as competitors, technological factors, partnerships, etc. For instance, an internal influencer for
the goal mentioned previously could be the: “availability of branches in
all major cities”.
To exemplify our approach, we use BMM as the goal modeling technique. Yet, the goal modeling technique i* can also be used for the same
purpose (Andersson et al., 2008). It was mentioned previously, that unfocused goal models make it difficult to develop goal-aligned business models.
We suggest overcoming this problem by formulating goals in terms of business model components. While goal models describe the intentions of actors
in a business context, business models describe activities that create and
exchange resources between actors. A common characteristic between them
in regards to enterprise modeling is that both of them are concerned with the
arrangement of resources and activities to optimize profits in business contexts. Actors want to make the best arrangement of creation and exchange of
resources (that is business models) according to their business goals (that is
goal models). Since the business models are focused on describing creation
of resources and transfer of them between business stakeholders, in a business context, the goals of actors largely concern acquisition, production,
maintenance, or provisioning of resources. Based on these observations, to
design a goal model we use the following set of rules as proposed in Andersson et al. (2008).
• A goal is defined as a desired condition on one or more features of a
resource.
• A means describes a course of action. This action could impact one or
several business model components.
• An influencer is defined as some condition that could lead to support,
review or remove one or more means.
• Conflicts between goals could be identified either at goal model level
considering their importance over one another or at the business level
when the means are realized by employing business model components.
At the goal model level, conflicts among goals are typically identified and
removed by evaluating their importance and determining which are to be
removed and which are to be preserved (Dardenne et al., 1993). In the business level, the business modeler could identify conflicting goals by considering means that lead conflicts among business model components. For instance, if some means lead to preventing the introduction of a certain com78
ponent while another means requires the same, the goals that lead to the
means are identified as having conflicts with each other.
4.4 Designing a goal-aligned business model
In this section, we present an overview of the method for designing a goalaligned business model. As depicted previously in Figure 12, the method
starts with a business scenario where a simple as-is business model can be
drawn. Then it creates a new business model using a goal model as an input.
The main instruments used in the method are the means templates and the
transformation rules.
The method has two main steps, where the first concerns goal modeling
and the second business modeling. The objective is to use the goal model
developed in the first step as an instrument to design a business model.
Step 1: Strategic Goal Modeling. In this step, the goal modeler elicits
goals of business stakeholders and constructs a goal model using the means
templates.
Step 2: Goal-aligned business modeling. In this step, the business modeler designs a business model based on the information in the goal model
produced in Step 1. In order to design the business model, the business modeler should complement the means by filling in the optional parts of the templates when needed. In this thesis, we make use of e3 value ontology to design the goal-aligned business model.
The above steps provide the overview of the method for designing goalaligned business models. Below, we discuss each step in detail providing
how the means templates should be used to develop a goal model and thereafter to derive components of the to-be business model.
4.4.1 Means templates
In this section, we discuss how strategic goal modeling in Step 1 is done.
Means play a key role in aligning a business model with a goal model.
Therefore, we propose more detailed rules, in the form of templates, for formulating means in a goal model. As stated in the previous subsection, almost
all means concern the acquisition, production, maintenance, or provisioning
of resources. In other words, means addresses the fundamental entities of
business models. Means describes with whom the principal actor exchanges
resources, what resources are exchanged and what value activities there are
to produce and consume these resources. Thus, it becomes possible to formulate next to all means according to a small number of templates.
The intuition behind a template is that it generally should form a triplet,
<Action, Resource, Actor>. For instance, in template 1 “offer resource to
actor”, offer corresponds to Action, resource to Resource, and actor to Actor.
79
The following syntax is used for the templates. Each template has two parts,
one compulsory and one optional, which is written within square brackets.
These two parts are more or less similar to strategic and tactic parts discussed in (Andersson et al., 2008). The compulsory part consists of information regarding the possible business strategies, for instance, offering, procuring and producing resources. The optional part describes possible actions
that could be carried out to fulfill the action named in the compulsory part.
Parentheses are used for grouping of alternatives. The components of the
group are separated by a pipe sign “|” with the standard exclusive-or interpretation. The “AND” sign is used to indicate a combination of parts with
the meaning that parts combined must all be present in the means. Words in
italics are non-terminals and are replaced by actual goal model terms when
formulating the means. An optional discriminator can be prepended to a
resource filling the same function as a grammatical adjective. A “good
book” is an example of a resource “book” prepended with the optional discriminator “good”.
The compulsory part contains the most important piece of information,
while the optional part provides complementary information about the consequences of the compulsory part. A goal modeler may choose to fill in the
optional part to provide complete information, but in many cases it is preferable to leave it out to make the goal model less complex.
The following nine means templates have been identified.
1. offer resource1 to actor1 [AND (start using conversion activity1 |
start producing resource1 | start procuring resource1 from actor2)][AND start receiving resource2 from actor1]
2. stop offering resource1 to actor1 [AND (stop procuring resource1
from actor2 | stop producing resource1)]
3. procure resource1 from actor1
[AND (start using resource1 in conversion activity1 | offer resource1 to actor2)][AND provide resource2 to actor1]
4. stop procuring resource1 from actor1 [AND (stop offering resource1 to actor2 | start producing resource1 in conversion activity1)]
5. start producing resource1 in conversion activity1 [AND start offering resource1 to actor2]
6. stop producing resource1 in conversion activity1 [AND (start procuring resource1 from actor1 | stop offering resource1 to actor2)]
7. (increase | decrease) production of resource1 in conversion activity1
8. insource production of resource1 in conversion activity1
9. outsource [fraction of] production of resource1 in conversion activity1
80
The above templates describe how means in a goal model should be structured and defined. In the next section, we present a set of actions, associated
with each means template, to add or change the as-is business model.
4.4.2 Transformation alternatives and transformation rules
It should also be noted that the means formulated according to means templates in the goal model may provide insufficient information to do the transformation. Thereby, a business modeler should be provided with additional
tools to complement any missing information in the templates. We try to
address this by defining the alternatives available for each means template
and defining rules that describe a basic set of actions associated with these
alternatives.
Considering the different combinations of compulsory and optional parts,
each means template can be broken down to a set of alternatives. We call
them transformation alternatives since they represent different choices that a
business modeler can use to transform the means in the goal model to activities in a business model. These transformation alternatives are used to define
transformation rules in the form of a conditional statement. For each means
template, there will be exactly one transformation alternative specifying how
the means of this template will influence the to-be business model. For each
transformation alternative, there will be exactly one set of actions in the
transformation rule that specifies what actions a business modeler should
perform to design the to-be business model. Designing the to-be business
model by the business modeler should be done in the following ways.
• By choosing a means given in the goals model, described in the form of
a means template and associate it with the appropriate transformation
alternative.
• By complementing the transformation alternative with actual instances
of the business notions in the means template.
• By applying the actions in the transformation rule corresponding to the
chosen transformation alternative.
The means templates can be categorized into three main groups based on
their effects on the to-be model: templates leading to the introduction of new
business model components, templates leading to the deletion of certain
business model components, and templates require some process level actions. While the first two groups have a visible effect on the to-be business
model, the effects of the means of the third group is not visible in this model
but will have an impact only on the process model.
Below, we define a set of transformation alternatives and a transformation
rule associated with each means template. The business modeler should
choose one of the transformation alternatives and then apply the corresponding actions in the transformation rule.
81
Template 1
offer resource1 to actor1
[AND (start using conversion activity1 | start producing resource1 | start procuring resource1 from actor2)]
[AND start receiving resource2 from actor1]
This template addresses the business activity of exchanging resources between actors. The compulsory part deals with the business activity of providing a resource to an actor. The first optional part addresses the origin of the
resource and offers three alternatives: using an existing conversion activity,
starting a new conversion activity in the principal actor to produce the resource, or procuring it from another actor. The second optional part specifies
what resource is received as compensation for the resource provided by the
principal actor. Following this, below we first outline transformation alternatives associated with this means template and then define the transformation
rule associated with them.
Transformation alternatives:
a. Offer resource1 to actor1 and receive resource2 from actor1.
b. Produce resource1 and offer resource1 to actor1 and receive resource2 from actor1.
c. Procure resource1 from actor2 by providing resource3 to actor2
and offer resource1 to actor1 and receive resource2 from actor1.
d. Stop producing resource1 and procure resource1 from actor2 by
providing resource3 to actor2 and offer resource1 to actor1 and
receive resource2 from actor1.
e. Stop procuring resource1 from actor2 and produce resource1 and
offer resource1 to actor1 and receive resource2 actor1.
Transformation rule
If alternative a is chosen then:
Add new actor if actor1 doesn’t exist.
Add new resource transfer to offer resource1 to actor1 and connect
this new resource transfer to an existing conversion activity.
Optionally, add new resource transfer to receive resource2 from actor1
Else if alternative b is chosen then:
Add new actor if actor1 doesn’t exist.
Add new conversion activity to produce resource1 and a new resource transfer to offer resource1 to actor1.
Optionally, add new resource transfer to receive resource2 from actor1.
82
Else if alternative c is chosen then:
Add new actor if actor2 doesn’t exist.
Add new resource transfer to procure the resource1 from actor2
and add new resource transfer to provide resource2 to actor2.
Add new actor if actor1 doesn’t exist and add a new resource transfer to offer resource1 to actor1
Else if alternative d is chosen then:
Delete the conversion activity that produces resource1 with the related resource transfers if this conversion activity only produces resource1.
Add new actor if actor2 doesn’t exist and add new resource transfer to procure the resource1 from actor2.
Add new resource transfer to provide resource2 to actor2, if necessary.
Add new actor if actor1 doesn’t exist and add a new resource transfer to offer resource1 to actor1.
Else if alternative e is chosen then:
Delete actor2 if there is only one resource transfer related to procurement of resource1 with actor2.
Delete the resource transfers related to procuring resource1 from
actor2.
Add new conversion activity to produce resource1.
Add new resource transfer to offer resource1 to actor1.
Add another resource transfer to receive resource from actor1 of
necessary.
Template 2
stop offering resource1 to actor1
[AND (stop procuring resource1 from actor2 | stop producing
resource1)]
This template addresses the issue of stopping providing a certain resource.
The optional part of the template has an effect only if the principal actor
stops offering the resource to all actors. In that case, the optional part says
that this can be done by either stopping producing the resource or by stopping procuring it from another actor.
Transformation alternatives:
a. Stop offering resource1 to actor1 and stop receiving resource2
from actor1
b. Stop procuring resource1 and stop providing resource2 to actor1
and stop offering resource1 to all.
c. Stop producing resource1 and stop offering resource1 to all.
83
Transformation rule
If alternative a is chosen then:
Delete resource transfers related to offering and receiving of resource1 and resource2 with actor1.
Delete actor1 if there are no other resource transfers with actor1.
If necessary delete conversion activity1 associated with deleted
resource transfers with actor1.
Else alternative b is chosen then:
Delete resource transfers related to procuring and providing of resource1 and resource2 respectively with actor1.
Delete actor1 if there are no other resource transfers with actor1.
Delete resource transfers related to resource1 with all actors.
Delete all actors associated with the exchange of resource1, if
there are no other resource transfers with them.
Else if alternative c is chosen then
Delete resource transfers related to offering and receiving of resource1 and resource2 respectively with all actors.
Delete conversion activity1 associated with resource1 if it does
not associate with any other resources.
Delete all actors associated with the exchange of resource1, if
there are no other resource transfers with them.
Template 3
procure resource1 from actor1
[AND (start using resource1 in conversion activity1 | start
offering resource1 to actor2)
AND start providing resource2 to actor1]
The compulsory part in this template is related to the procurement of a resource by the principal actor from another actor. The optional part describes
the possible effects of the procurement of the resource. The resource procured may be used as an input to produce a certain resource or it may be
offered directly to the principal actor’s customers.
Transformation alternatives:
a. Procure resource1 from actor1 and provide resource2 to actor1
and use resource1 in conversion activity1.
b. Procure resource1 from actor1 and provide resource2 to actor1
and offer resource1 actor2 and receive resource3 from actor2.
c. Stop producing resource1 in conversion activity1 and procure resource1 from actor1 and provide resource2 to actor1 and offer resource1 to actor2 and receive resource3 from actor1.
84
Transformation rule
If alternative a is chosen then:
Add new actor if actor1 doesn’t exist.
Add new resource transfer to procure the resource1 from actor1
and add new resource transfer to provide resource2 to actor1.
Connect new resource transfers to conversion activity1 if it exists
or add conversion activity1 and associate new resource transfers.
Else if alternative b is chosen then:
Add new actor if actor1 does not exist.
Add new resource transfer to procure the resource1 from actor1
and add new resource transfer to provide resource2 to actor1.
Add new actor if actor2 does not exist
Add a new resource transfer to offer resource1 to actor2 and receive resource3 from actor2
Else if alternative c is chosen then:
Delete conversion activity1 associated with resource1 if it does not
associate with any other resources.
Add new actor if actor1 does not exist.
Add new resource transfer to procure the resource1 from actor1
and add new resource transfer to provide resource2 to actor1.
Add new actor if actor2 does not exist.
Add new resource transfers to offer resource1 to actor2 and receive
resource2 from actor1 or associate existing resource transfers related to resource1 and resource2 with conversion activity1
Template 4
stop procuring resource1 from actor1
[AND (stop offering resource1 to actor2 | stop using resource1 in conversion activity1 |start producing resource1 in
conversion activity1)]
This template addresses the issue of stop procuring a resource from
another actor. The possible effects of this action are that the principal actor
may have to start the production of the resource in order to be able to continue providing the resource to the customers or he may have to stop offering
that object. However, the actions in the optional part depend on whether the
principal actor stops procuring the resource from all the suppliers or not.
Depending on that, one of the alternatives in the optional part is chosen.
Transformation alternatives:
a. Stop procuring resource1 from actor1 and stop providing resource
2 to actor1 and stop offering resource1 to all.
b. Stop procuring resource1 from actor1 and stop using resource1 in
conversion activity1.
85
c. Stop procuring resource1 from actor1 and stop providing resource2 to actor1.Produce resource1 in conversion activity1 and
offer resource1 to actor1 and receive resource2 actor1.
Transformation rule:
If alternative a is chosen then:
Delete resource transfers related to procuring and providing resource1 and resource2 respectively with actor1.
Delete actor1 if there are no other resource transfers with actor1.
Delete resource transfers related to resource1 with all actors.
Delete all actors associated with the exchange of resource1, if
there are no other resource transfers with them.
Else if alternative b is chosen then:
Delete resource transfers related to procuring and providing of resource1 and resource2 respectively with actor1.
Delete actor1 if there are no other resource transfers with actor1.
Delete conversion activity1 if it does not have associations to
other resources.
Else if alternative c is chosen then:
Delete resource transfers related to procuring and providing of resource1 and resource2 respectively with actor1.
Delete actor1 if there are no other resource transfers with actor1.
Add new conversion activity if conversion activity1 does not exist.
Add new actor if actor2 does not exist.
Add new resource transfer to offer the resource1 to actor2 and
add new resource transfer to receive resource2 to actor1. If these
resource transfers exist, associate these resource transfers with
conversion activity1.
Template 5
start producing resource1 in conversion activity1
[AND start offering resource1 to actor2]
The above template states that if the production of a resource is started
then it must be offered to some actor.
Transformation alternatives:
a. Produce resource1 in conversion activity1 and offer resource1 to
actor1 and receive resource2 actor1
b. Stop procuring resource1 from actor1 and stop providing resource2 to actor1. Produce resource1 in conversion activity1 and
offer resource1 to actor1 and receive resource2 actor1.
86
Transformation rule
If alternative a is chosen then:
Add new conversion activity if conversion activity1 does not exist.
Add new actor if actor2 does not exist.
Add new resource transfer to offer the resource1 to actor2 and
add new resource transfer to receive resource2 to actor1.
Else if alternative b is chosen then:
Delete resource transfers related to procuring and providing of resource1 and resource2 respectively with actor1.
Delete actor1 if there are no other resource transfers with actor1.
Add new conversion activity if conversion activity1 does not exist.
Add new actor if actor2 does not exist.
Add new resource transfer to offer resource1 to actor2 and add
new resource transfer to receive resource2 to actor1. If these resource transfers exist, associate these resource transfers with conversion activity1.
Template 6
stop producing resource1 in conversion activity1
[AND (start procuring resource1 from actor1 | stop offering
resource1 to actor2)]
The compulsory part in this template deals with the issue of stopping the
production of a resource. The optional part describes the possible actions to
deal with that situation. The first choice is to start procuring the resource in
order to offer it to the customers. The other option is to stop offering the
resource to all the customers.
Transformation alternatives:
a. Stop producing resource1 in conversion activity1 and procure resource1 from actor1 and provide resource2 to actor1. Offer resource1 to actor2 and receive resource2 from actor2.
b. Stop producing resource1 in conversion activity1and stop offering resource1 to all.
Transformation rule
If alternative a is chosen then:
Delete conversion activity1 associated with resource1 if it does not
associate with any other resources.
Add new actor if actor1 does not exist.
Add new resource transfer to procure the resource1 from actor1
and add new resource transfer to provide resource2 to actor1.
87
Add new actor if actor2 does not exist.
Add new resource transfers to offer resource1 to actor2 and receive
resource2 from actor1 or associate existing resource transfers related to resource1 and resource2 with conversion activity1.
Else if alternative b is chosen then:
Delete resource transfers related to offering and receiving of resource1 and resource2 respectively with all actors.
Delete conversion activity1 associated with resource1 if it does
not associate with any other resources.
Delete all actors associated with the exchange of resource1, if
there are no other resource transfers with them.
Template 7
(increase | decrease) production of resource1 in conversion
activity1
This template deals with the increment or decrement of the production of
a resource. Furthermore, means of this kind have no effect on the business
model but only on the process model.
Template 8
insource production of resource1 in conversion activity1
This template considers the situation where the production of a resource is
insourced. If the production is insourced, then it will lead either to an increase of the production in an existing conversion activity or to start a new
conversion activity to produce the resource. In this case too, the actions under b have no visible effects on the business model. Thereby alternative b is
not considered in the transformation rule.
Transformation alternatives:
a. Insource production of resource1 and offer resource1 to actor1
and receive resource2 from actor1. Stop procuring resource1 from
actor1 and stop providing resource2 to actor1.
b. Insource fraction of production of resource1 and decrease fraction
of procuring resource1.
Transformation rule
If alternative a is chosen then:
Add new conversion activity if conversion activity1 does not exist.
Add new actor if actor2 does not exist.
Add new resource transfer to offer resource1 to actor2 and add
new resource transfer to receive resource2 to actor1.
88
Template 9
outsource [fraction of] production of resource1 in conversion
activity1
This template is applicable to the situation where the production of a resource is outsourced, which will lead to either a decrease or stopping of production. In addition to that the principal actor must also start procuring the
resource, whose production has been outsourced, and start providing a resource as compensation. Outsourcing a fraction of production will primarily
affect on a process level rather than business level. However, procuring the
outsourced fraction will have a visible effect similar to bullet a in the list.
Transformation alternatives:
a. Outsource production of resource1 to actor1 and procure resource1 from actor1 by providing resource2 to actor1
b. Outsource fraction of production of resource1 to actor1 and decrease fraction of production of resource1 in conversion activity
and procure resource1 from actor1 by providing resource2 to actor1
Transformation rule
If alternative a is chosen then:
Add new actor if actor1 does not exist.
Add new resource transfer to procure the resource1 from actor1
and add new resource transfer to provide resource2 to actor1.
The alternatives and rules defined above deal with basic business notions
such as resource transfers, resources, value activities and actors and basic
actions associated with them such as introduction, deletion that should be
performed by business modeler. In addition to them, a business modeler
should be able to identify general actions which need to be performed. For
instance, he should be able to identify when a new resource transfer can associate with an existing conversion activity instead of introducing a new
conversion activity.
In the next section we illustrate the method application considering several means in the goal model.
4.4.3 Modeling specifics
When designing the business model, the following rules must be considered
to ensure that the final business model is created according to the semantics
of the e3 value ontology.
89
• Resources and resource transfers and conversion activities are mapped to
value objects, value transfers and value activities in an e3 value business
model.
• Every value transfer must have a direction. The direction “out” or “in”
indicates the offering actor and receiving actor of a resource, respectively.
• An outgoing/incoming value transfer must be grouped together with at
least one incoming/outgoing resource transfer to ensure the economic reciprocity.
• Potential alternatives, for the transfer of the same value objects, should be
considered when grouping value transfers. For instance, in a situation
where a firm offers two value objects; goods and delivery, in return for
payment, potential alternative value object bundles may be goods in return for payment and, goods and delivery in return for payment. In an e3
value business model, these alternatives should be modeled by grouping
them into two value interfaces, thus allowing the flexibility to perform
one set of transfers for any given customer.
• Appropriate join or split (“AND” or “OR”) conditions must be used to
indicate possible alternative resource offerings or connections of more
than one value interface to a single value activity.
4.4.4 Application of the method to the eye-care health case
In this section, we apply the method for designing a goal-aligned business
model to the eye-care health scenarios presented in Section 2.7.2. Following
the method presented in above sections, we first build the goal model which
will then be used to design the business model.
4.4.4.1 Designing the goal model
The analysis regards the patient’s demand to get the right treatment, which is
therefore articulated as a major goal for the primary care physician and the
healthcare specialist. This major goal is further refined into a set of sub-goals
to create a goal tree which is further refined to identify a course of action,
i.e. means.
Using the outlined definitions for goals, means and influencers in Section
4.3, Figure 14 shows a goal model for the eye-care health case scenario from
Section 2.7.2. The major goal is refined further in two branches considering
the primary care physician and the healthcare specialist. Since the patient is
the consumer of treatment services from the primary care physician and
healthcare specialist, the patient’s intentions are considered when the goals
of the latter two are derived. Therefore, the goals of the patient are not explicitly modeled in the goal model in Figure 14.
90
Considering the patient’s demand to get the right treatment, the major goal
(Goal 1) is defined as “Level of treatment (resource) shall be right (feature)”.
Considering the primary healthcare center, the major goal is refined into
the goal (Goal 2); “Diagnosis (resource) shall be correct (feature)”. Two
sub-goals; (Goal 3) “Knowledge (resource) about the disease shall be high
(feature)” and (Goal 4) “Treatment or referral (resource) shall be available
(feature)”. The means (Means 1); “Procure knowledge on symptoms and
disease” is identified as the course of action to achieve Goal 3. The influencer “Availability of various sources of gaining knowledge” is identified as an
opportunity that supports the Means 1. The means; (Means 2) “Offer right
to give advance treatment to Patient”, (Means 4) “Offer treatment to patient” and (Means 3) “Offer right to get advance treatment to Patient” are
identified as a course of actions to achieve Goal 4. Furthermore Goal 4 is
further refined to “List of special clinics and their competencies (resource)
shall be available (feature)” (Goal 5). Means 5 “Offer information on
healthcare specialist clinics” supports achieving Goal 5.
Taking the healthcare specialist into account, Goal 1 is refined to “Level
of treatment (resource) shall be advanced (feature)” (Goal 6). We identify
the means “Offer advance treatment to Patient” (Means 6) as a course of
action to achieve Goal 6. Furthermore, as influencer “Availability of improved healthcare facilities” is identified as an opportunity that supports this
course of action. Goal 6 is further refined into “Patient information (resource) shall be accessible (feature)” (Goal 7) which is achieved through the
means “Offer access to treatment status to Patient” (Means 7).
The goals and means derived above are depicted in Figure 14.
Figure 14. Goal model for the eye-care health case
Every means elicited in Figure 14 follows the structure of the means templates as they are defined in the previous section. As such, they provide a
91
basis for structuring certain components in the business model. Furthermore,
some means elicit both the compulsory strategic parts and the optional parts,
while some others focus only on the strategy. For instance, in the primary
care physician means ‘‘Offer treatment’’, only the strategic part is provided.
In contrast, the means ‘‘Offer information on specialized clinics and start
procuring’’, suggests even the tactics, i.e., to obtain the information on clinics by procuring it from another actor.
4.4.4.2 Designing the goal-aligned business model
In this section, we illustrate the method for designing the goal-aligned business model. For illustrative purposes, we use means in the goal model in
Section 4.4.4.1 and apply the method outlined in Section 4.4.
Each means in the goal model is addressed by applying one transformation rule. According to the method this should be done in three steps: first
selecting the means template before complementing the means with the optional part of the template, and finally applying the transformation rule.
Means 1: Procure knowledge on symptoms and diseases in diagnosing.
• Step 1: Select transformation alternative.
Procure resource1 from actor1 by providing resource2 and use resource1
in conversion activity
• Step2: Complement the transformation alternative by replacing business
model notions by actual instances.
Procure knowledge on symptoms and diseases (resource1) from Health
services office (actor1) by providing Registration (resource2) and use
knowledge on symptoms and diseases (resource1) in Diagnosing and referring special care (conversion activity)
• Step 3: Apply corresponding actions in the transformation rule.
Introduce new Actor Health services office (actor1) to procure knowledge
on symptoms and diseases (resource1).
Add one resource transfer for procuring knowledge on symptoms and diseases (resource1) from Health services office (actor1) to Primary care
physician.
Add another resource transfer to provide Registration (resource2) as a
compensation for knowledge on symptoms and diseases (resource1)
Connect new resource transfers to the Diagnosing and referring special
care (conversion activity).
The actions in Step 3 will lead to introduce a new actor, Health services
office (see Figure 15), to procure the knowledge on symptoms and diseases.
Furthermore there will be two new resource transfers between the primary
care physician and the new actor, Health services office, for procuring knowledge on symptoms and diseases and for providing registration as a compen92
sation for procuring the resource. These new resource transfers will be connected to the conversion activity treatment and referring to special care in
the primary care physician.
Means 2 – Offer Right to give advance treatment to Healthcare specialist.
• Step 1: Select transformation alternative.
Offer resource1 to actor1 and start receiving resource2 from actor1
• Step 2: Complement the transformation alternative by replacing business
model notions by actual instances.
Offer Right to give advance treatment to Healthcare specialist (actor1).
• Step 3: Apply corresponding actions in the transformation rule.
Add a new resource transfer for offering Right to give advance treatment
(resource1) from Primary care physician to Healthcare specialist (actor1).
The action in Step 3 will lead to the addition of two new resource transfers to offer Right to give advance treatment and Fee. Considering the fact
that the Healthcare specialist must be provided referral (right to give treatment) together with the offering of referral (right to get treatment) to the
patient, this resource transfer will be offered via the same interface as the
Right to get advance treatment from the Primary care physician to the Patient.
Means 3 – Offer Right to get special treatment (referral) to Patient.
• Step 1: Select transformation alternative.
Offer resource1 to actor1 and start receiving resource2 from actor1
• Step 2: Complement the transformation alternative by replacing business
model notions by actual instances.
Offer Right to get special treatment (referral) to Patient (actor1) and start
receiving Fee (resource2) from Patient (actor1)
• Step 3: Apply corresponding actions in the transformation rule.
Add a new resource transfer for offering Right to get special treatment
(referral) (resource1) from Primary care physician to Patient (actor1).
Add new resource transfer to provide Fee (resource2) as compensation
for Right to get special treatment (referral) (resource1).
The actions in Step 3 will lead to the addition of two new resource transfers to offer Right to get special treatment (referral) and Fee. Considering
the fact that a patient must get some form of treatment from a primary care
physician before being referred to a healthcare specialist, we model this as
an alternative of Treatment (in return for fee), resource offering, thereby
making the resource; treatment included in this grouping by default. As such
in the business model in Figure 15, these two resource transfers are modeled
together with the resource treatment as an alternative to, treatment in return
for fee, in a separate interface.
93
Means 4 – Offer treatment to Patient.
• Step 1: Select transformation alternative.
Offer resource1 to actor1 and start receiving resource2 from actor1
• Step 2: Complement the transformation alternative by replacing business
model notions by actual instances.
Offer treatment to Patient (actor1) and start receiving Fee (resource2)
from Patient (actor1).
• Step 3: Apply corresponding actions in the transformation rule.
Add a resource transfer for offering treatment (resource1) from Primary
care physician to Patient (actor1).
Add another resource transfer to provide Fee (resource2) by Patient (actor1) as compensation for treatment (resource1).
The actions in Step 3 will lead to the addition of two resource transfers;
treatment and Fee. These two resource transfers are connected to the conversion activity; treatment and referring to special care.
Means 5 – Offer Information on Healthcare specialist clinics
• Step 1: Select transformation alternative.
Offer resource1 to actor1 and start procuring resource1 from actor2 and
start receiving resource2 from actor1
• Step 2. Complement the transformation alternative by replacing business
model notions by actual instances.
Offer to Information on Healthcare specialist clinics (resource1) Patient
(actor1) and start procuring Information on Healthcare specialist clinics
(resource1) from Health services office (actor2) and start receiving Fee
(resource2) from Patient (actor1)
• Step 3: Apply corresponding actions in the transformation rule.
Add a new resource transfer for procuring Information on Healthcare
specialist clinics (resource1) from Health services office (actor2) to Primary care physician.
Add new resource transfer to offer Information on Healthcare specialist
clinics (resource1) to Patient (actor1).
The actions in Step 3 will lead to the introduction of a new actor – Health
services office to procure the Information on Healthcare specialist clinics
(see Figure 15). Thereby, there will be two new resource transfers between
Primary care physician and the Health services office, for the procurement of
this new resource. This new resource could be obtained within already established value interface in the Means 1. Thereby, the new resource transfer
will be added to this existing value interface (see Figure 15). These new
transfers are connected to the conversion activity Treatment and Referring to
special care in the Primary care physician. Also to offer Information on
94
Healthcare specialist clinics to Patients, another resource transfer will be
added to the model. Since this information is offered to Patients who are
referred to healthcare specialists, the corresponding resource transfer is added to an existing value interface (that offers right to advance treatment) between the Primary care physician and the Patient.
Means 6 – Offer Advance treatment to Patient.
• Step 1: Select transformation alternative.
Offer resource1 to actor1 and start receiving resource2 from actor1
• Step 2: Complement the transformation alternative by replacing business
model notions by actual instances.
Offer advance treatment to Patient (actor1) and start receiving Fee (resource2) from Patient (actor1).
• Step 3: Apply corresponding actions in the transformation rule.
Add a resource transfer for offering advance treatment (resource1) from
Primary care physician to Patient (actor1).
Add another resource transfer to receive Fee (resource2) from Patient
(actor1) as compensation for advance treatment (resource1).
The actions in Step 3 will lead to the addition of two resource transfers;
Advance treatment and Fee. The conversion activity; Specialist Treatment is
used to produce the resource; advance treatment and hence these two resource transfers are connected to this conversion activity.
Means 7 – Offer Access to treatment status to Patient
• Step 1: Select transformation alternative.
Produce resource1 and offer resource1 to actor1 [and receive resource2
from actor1]
• Step 2: Complement the transformation alternative by replacing business
model notions by actual instances.
Produce Access to treatment status (resource1) and offer Access to treatment status (resource1) to Patient (actor1).
• Step 3: Apply corresponding actions in the transformation rule.
Add one conversion activity in the Healthcare specialist to produce
Access to treatment status (resource).
Add one resource transfer for Access to treatment status (resource) from
Healthcare specialist to Patient in an existing value interface.
Produce Access to treatment status (resource) using the conversion activity Specialist treatment and connect new resource transfer to it.
Offering Access to treatment status leads to the addition of one resource
transfer from the Healthcare specialist to the Patient. As there will be no
resource received as compensation to offering the resource Access to treat95
ment status, it will be produced by using an existing conversion activity Specialist treatment and will be offered via an existing value interface (that offers advance treatment).
Figure 15 shows the result of applying the method to the eye-care case
presented in Section 2.7.2.
Figure 15. Goal-aligned business model for the eye-care case
4.5 Summary
In this chapter, we have presented a method for aligning business models
with goal models. The method takes a goal model and an as-is business
model as inputs and transforms the as-is business model into a new business
model that conforms to the goal model. Goal and business model are primarily linked to each other through the notion of means. To facilitate means
formulation, a number of templates have been proposed. We have argued
that these templates cover a large part of the basic activities of an enterprise:
acquire, provide, produce, or maintain resources. The proposed approach
offers a number of benefits. Firstly, formulating goals and means in terms of
business model notions not only benefits a business modeler but also benefits a goal modeler. For a goal modeler, it provides a method for developing
uniform goal models. For a business modeler, it describes the intention of
96
business stakeholders in a more business-oriented way using clear businessoriented expressions. The goal-aligned business modeling method also helps
to design business models that are well-founded and firmly based on intentions of business stakeholders. Since the components of the business model
are directly motivated by the goal model, it enhances traceability between
business model elements and business intentions that lead to the identification of these elements. The method could also assist business users to assess
whether or not a designed business model correctly interprets and models
their business intensions. In addition to the above, the proposed method can
also be used as an explorative basis for eliciting and designing e-services
(e.g. Andersson et al., 2008). The method can also be used as a basis for
formalizing goal and business alignment (Jayaweera & Petit, 2009).
97
98
5 Analyzing Business Collaborations to
Improve Business Modeling
5.1 Introduction
The major task in business modeling concerns the identification of resources,
and their transfer among the involved actors. However, in this context, there
is still a lack of systematic approaches for creating more exploratory business models in regards to how consumers evaluate offered values and how
values are derived along different phases of business collaborations. In this
chapter, we discuss how business collaborations with different objectives
can be used to overcome these shortcomings.
Business collaborations occur with the aim of achieving different business
objectives. In some situations, actors collaborate with each other with the
aim of increasing the knowledge about goods, services, and product preferences, or even as a means of establishing certain business commitments for
the future. Business actors could also collaborate with each other with the
aim of exchanging objects of value such as goods, services, etc. Thereby,
from the collaboration perspective, there seems to be different purposes of
business collaborations, such as establishing commitments for the future, or
fulfillment of those commitments, their maintenance, etc.
Consumers characterize a value based on various factors – such as the
cost, the fitness to their needs, the time and effort they have to use to obtain
the value, and so forth (Weigand et al., 2007). These factors may be classified into different facets, such as interactive, relativistic, preference and experience (Holbrook, 1999). Since the value of an object may lie either in the
object itself or it may be elicited at the time the object is consumed (Holbrook, 1999), it is important to investigate all the stages of a business collaboration to identify what values an enterprise aims to offer. Therefore, we
examine the interaction between an enterprise and its customers from two
perspectives: collaboration life cycle and value perspectives to identify different objects offered at each stage, and the value these objects provide to
customers.
From the collaboration life cycle perspective, a business passes through
several phases. ISO Open-edi initiative (ISO/IEC, 2002) defines a business
99
transaction as consisting of five phases: planning, identification, negotiation,
actualization and post-actualization. These phases encompass the activities
to identify resources, establish relationships between the actors, transfer
resources between them, as well as the activities related to post-sale services.
From the value perspective, each of these activities may transfer some resource that has some value to participants in a business collaboration. Thereby, a problem is how to consider the different purposes of business collaborations mentioned previously in business modeling and identify resources
along different phases such as planning, identification, negotiation actualization and post-actualization? From the business-IT alignment perspective, any
method to create more explorative and strategically-aligned business models
should consider the activities from the planning up to the post-actualization
services.
Following the outlined concerns above, we think a better approach for obtaining an explorative enterprise business models is to identify different
types of business transactions, analyze the consumer values and thereby
identify the resources that are to be exchanged across the whole business
collaboration life cycle. The final objective is the obtainment of an explorative business model, which can be used as a prosperous basis for identifying
the e-services of the involved enterprises. To achieve that is the research
objective of this paper.
In this chapter, we analyze different types of business collaborations and
thereby identify the resources that are to be exchanged in planning, identification, negotiation, actualization and post-actualization phases of these collaborations. The final objective is the obtainment of a value-explorative
business model, which, thereby, can be used as a comprehensive basis for
identifying the e-services. Figure 16 below depicts the overview of the approach presented in this chapter.
Figure 16. Method overview
100
5.2 Classifying business transactions
Business collaborations occur in different ways. In some cases, customers
need to register some information prior to the actual transfer of the acquired
resources. For example, a person may need to register himself in a healthcare
unit before getting a medical treatment from it. This ordering of activities
happen due to various reasons, such as:
a. the risks associated with the resource transfer; and
b. the need for the assessment and allocation of human and other resources required to handle customer demands, and so forth.
In some other cases however, buyers do not necessarily need to provide
some personal and product-related information to establish commitments
before the actual transfer of resources. For instance, to purchase a book from
an online book shop, a customer may only need to provide his credit card
information as a means of making the payment. In such cases, there will not
be any transaction aiming to establish commitments prior to the actual resource transfer. Following the described, we identify the two major transaction types.
Future settlement-oriented
In these transactions, actors collaborate with the aim of exchanging information such as personal details (e.g. complete an authorization), product preferences, etc. The main concern here is to attract customers and expectantly
establish specific commitments for future transactions for selling actual
products or goods. The goals of these transactions may be twofold. A provider may engage with a customer with a goal of providing a specific product over a certain time period. He could also have a goal of identifying customer preferences, i.e. advertising his products to make customers aware of
them. In the latter case, the transaction would not be aiming at selling some
specific product or service within a particular time frame, but only to make
an awareness of the available resources. Considering these two goals, we
distinguish product-dependent and product-independent transactions.
Immediate settlement-oriented
In immediate settlement-oriented transactions, collaborating parties start
with providing resources, i.e. goods, services, and also prepare and complete
the resource delivery. As we have explained above, certain businesses require having an authorization transaction established between the resource
provider and the customer before a potential resource transfer occurs. In
such cases, we call the transaction concerning the transfer of resources as
dependent on an authorization. An example would be that a patient seeking
medical treatment at a local healthcare unit may first need to perform an
authorization from the latter by means of obtaining an acceptance registration in it. However, obtaining an authorization is not a must in every busi101
ness. For example, to buy some goods from an online shop, a customer may
only need to provide their credit card information as a means of making the
payment. In such cases, the actual transfer of goods is authorization independent.
Considering the two categories of business transactions identified above
and their sub-classifications, in the following, we distinguish four basic
transaction types for business collaborations:
1.
2.
3.
4.
Future settlement-oriented, product-independent.
Future settlement-oriented, product-dependent
Immediate settlement-oriented, authorization-dependent
Immediate settlement-oriented, authorization-independent
In what follows we discuss possible dependencies among the outlined
transactions, to get an understanding of possible orderings of their execution.
The first two transaction types do not involve the actual transfer of the resources. The first transaction (1), focuses on exchanging personal and product related information. Here, the involved actors do not identify the concrete products or services to be exchanged. As such, this transaction cannot
be a prerequisite for other transaction types in the list. In the second transaction (2), actors exchange not only personal and product-related information
but also agree on the products or services to be later exchanged. As such, it
must precede an immediate settlement-oriented, authorization-dependent
transaction type (3). Since the resource types had been already identified in a
future settlement-oriented transaction, here actors set the focus on agreeing
on facilitating services such as delivery, or allocation of human and other
resources. Regarding the fourth transaction type in the list, the actors agree
both on the resources to be exchanged and completing the delivery, and
therefore this transaction type is not dependent on any other one.
In the following section, we identify different types of resources transferred in each of the defined transaction types along the five fundamental
activities defined in Open-edi: planning, identification, negotiation, actualization and post-actualization. In the process of identifying different types of
resources, we consider resource types: goods, services, rights and information as discussed in Section 3.2. As was mentioned previously, core resource
transfers that occur in the actualization phase are often considered in business modeling. However, if we need to use a business model as a basis to
capture requirements for an e-business application, it is beneficial to have a
detailed analysis around the fundamental activities of a business transaction.
This is to identify a comprehensive set of resources transferred between the
actors.
102
5.3 Creating design templates for business transaction
types
From a business modeling perspective, the activities performed in the Openedi phases, may be defined as follows: in the planning and identification
phases, actors and resources are identified respectively; in the negotiation
phase the commitments to particular resource exchanges are established; in
the actualization phase the agreed resource transfers are carried out, and in
the post-actualization phase possible complaints are entertained. To elicit
resources across these phases, we utilize categories of resources discussed in
Section 3.2.
Considering these aspects we use five phases proposed by the Open-edi
framework (ISO/IEC, 2002) as discussed below.
In the planning phase, actors exchange resources primarily of informational value to each other. These could include, information regarding products such as catalogues and information regarding the services such as customer registration (see Figure 17).
In the identification phase, the customer is primarily responsible for introducing himself to the provider by offering information such as personal
information and product preferences to the provider. A provider could use
such information, for instance to determine the ways to achieve his business
goals. As an example, a provider may use customer product preference information to determine how to increase the offerings resource. Additionally,
the provider is responsible for provisioning additional information regarding
resources to be delivered in the actualization phase (see Figure 17).
In the negotiation phase, the provider and the customer establish commitments by exchanging rights regarding resources. These rights may be
related to a particular product that will be offered later or it could well be
about a service such as customer registration or about both. It is also possible
that the customer and the provider agreed on possible rights regarding the
post sale services. For instance, in a regional healthcare center, the healthcare service provider and the patient may agree on possible services regarding post-treatment examinations to evaluate health status (see Figure 17).
In the actualization phase, the provider delivers the product as agreed in
the negotiation phase and the customer completes or starts making payment
for the products delivered to him (see Figure 17).
In the post-actualization phase the provider may offer post-sale services
agreed in the negotiation phase (see Figure 17). Typical examples could be
post health examinations offered to patients by a healthcare provider.
Considering them, we summarize possible resource types transferred in
each phase.
103
Figure 17. Possible resources transferred in different phases of a business transaction
In the following section, we discuss different transaction types identified
in Section 5.2 and propose a template for each transaction type by outlining
major resource transfers in each of the phases as described above. We outline the proposals in the form of e3 value model templates.
5.3.1 Future settlement-oriented, product-independent
transactions
This type of transaction focuses on a prospective buyer registration, independent of any resource transfers. The primary aim is to make the buyer
aware of the products of a company. This type of transaction involves the
transfer of the economic resources aiming at increasing the knowledge of
actors. For example, personalized recommendations offered by Amazon.com
to its registered users aim to make them aware of the items of their preferences.
The resources transferred between the actors in this transaction are mainly
restricted to information resources. However, it is also possible that a provider sends some other complementary resources as a means of advertising
his products.
In Section 2.4.2, we gave a brief overview of the different phases in business transactions defined by (ISO/IEC, 2002). Further, in Section 5.3, these
phases are discussed in relation with the e3 value ontology. Thereby, in the
following, we outline different categories of resources exchanged in different Open-edi phases of a business collaboration conforming to the future
settlement-oriented, product-independent transaction type. In the planning
phase, a provider may offer a certain level of information regarding the
products in general and the information regarding the registration service
and its availability. Since the transaction aims to establish commitments
between actors without committing to a specific economic resource, identification and negotiation may be performed in a single continuous interactive
dialogue where customers submit information requested by the provider and
eventually agree on the terms and conditions of using the registration service. In contrast, actualization may happen over a period of time until the
104
relationship ends at a mutually agreed way. Though no clear margin can be
drawn to identify activities in the planning, identification, and negotiation
phases, we can tentatively identify the activities in these phases as shown
below.
Planning: In the planning phase, the provider offers the information regarding the data required by the registration service to the customer (Reg. service
info).
Identification: The customer submits information requested by the registration service (Personal info).
Negotiation: The customer accepts the terms and conditions and receives the
registration from the provider (Registration).
Actualization: The provider offers product-related information to the registered user (Product-related info).
The e3 value model in Figure 18 depicts this transaction.
Figure 18. Template 1: e3 value model for a future settlement-oriented, productindependent transaction
Although the given business template is modeled as a collaboration between
two actors, in practice the provider may use an intermediate for the provisioning of the discussed resources. However, since the focus in this transaction type is to model the interaction between the customer (of a registration
service) and the provider, we do not include a third actor.
5.3.2 Future settlement-oriented, product-dependent
transactions
In some businesses, the customer registration becomes a prerequisite for the
actual transfer of economic resources. For example, a resident needs to be
registered at a primary healthcare center before he or she gets medical treatment. This registration could happen well before someone receives a medical
treatment. Thereby, these are two separate transactions aiming to achieve
different objectives where the first aim is to achieve the registration of patients and the second treating the patients.
105
The transactions of this type may have two particular goals: register customers and establish rights regarding a particular resource. Accordingly, in the
planning phase, the provider offers both registration service information and
product information. The customer subsequently, provides the information
required by the registration service in the identification phase. In the negotiation phase the customer receives registration and also, the right to receive
resource, later by a different transaction. The right to resource that the customer receives in the negotiation phase is a conditional one in the sense that
certain conditions such as payment on delivery of the resource may be applied when the resource is actually delivered later on by a different transaction. In the actualization phase, the provider may offer updated information
about the resource to registered customers.
In the following, we outline possible resources exchanges at different
phases for the transaction type in discussion:
Planning: The provider offers information regarding the registration service
in connection with the resource committed to offer later (Registration service info).
Identification: The customer offers information needed for registration (Personal info).
Negotiation: The provider grants registration and thereby the right to receive
the resource (possibly later, by a different transaction) to the customer (Right
to receive resource).
Actualization: The provider offers resource-related information to the registered customers (Updated resource info).
In Figure 19, we depict the described transaction using an e3 value model.
Figure 19. Template 2: e3 value model for a future settlement-oriented, productdependent transaction type
The above figure models the commitment establishment stage for a particular resource. The commitment fulfillment stage is modeled within a different template in Section 5.3.3. This is basically to make the template flexible to handle a situation where a registered user may not consume his right
to receive a resource obtained at the commitment establishment stage. For
106
example, a registered resident may never take medical treatment and in such
a case the template should be able to handle it.
5.3.3 Immediate settlement-oriented, authorization-dependent
transactions
We have explained in Section 5.2 that an immediate settlement-oriented,
authorization-dependent transaction requires the future settlement-oriented,
product-dependent transaction to be carried out first (i.e. template 2). In the
following we go through the planning, identification, negotiation, actualization and post-actualization phases and identify the different types of resources transferred in each phase.
Planning: Since the resource types are already identified in the future settlement-oriented, product-dependent transaction, planning need not be performed.
Identification: The registered customers submit the registration information
to the provider (Accreditation).
Negotiation: Since the right for the resource has been established earlier (i.e.
using transaction template 1, here the provider and the customer may engage
in negotiations regarding the facilitating services such as time allocation,
delivery of the resource, third actors involved in the transaction, etc (Right to
additional resources). In addition to that, the customer makes an obligation
to pay, for instance by providing their credit card information (Right to payment).
Actualization: The customer gets the custody of the resource. The provider
gets the compensation, for example, money (Payment, Resource).
Post-actualization: Post-sale services may be performed by the provider
according to a possible commitment established in the preceding transaction
(template 2) (Post sale services).
Figure 20. Template 3: e3 value model for an immediate settlement-oriented, authorization-dependent transaction type
In template 3, we model right to payment and payment as two resource
transfers from customer to provider. In reality the provider may receive credit card information from the customer and the actual payment (money) from
a third actor (e.g. bank). The same is true regarding the transfer of the re107
source from the provider to the customer. Although, we model this transaction from the provider to the customer, in reality a third actor may be involved in the delivery of resource.
5.3.4 Immediate settlement-oriented, authorizationindependent transactions
In some businesses, the customer registration is not a required activity for
the transfer of economic resources. For example, when someone buys a book
from a conventional book shop, the buyer does not necessarily register himself. Even in Web-based transactions, buyers may only need to provide information to register their payment obligations such as credit card details.
In the following, we examine the planning, identification, negotiation, actualization and post-actualization phases, to identify the types of resources
transferred at each phase.
In the planning phase of this type of transactions the provider may offer
general information about the resource. An additional resource specific information, terms and conditions under which the transaction may work out
could be offered by the provider to the customer in the identification phase.
In the negotiation phase the buyer will get the right to the resource and the
provider will get the obligation to make the payment. The buyer will receive
the resource and the provider will receive the payment in the actualization
phase. The provider may offer post-sale services in the post-actualization
phase.
Planning: The provider offers information regarding the concerned resource
(Catalogue).
Identification: The provider may send additional information requested by
the buyer (Product specific info).
Negotiation: The provider offers the right to the resource to the buyer (Right
to resource). The buyer offers the right to payment (obligation to make payment) to the provider (Right to payment). This may possibly be a resource
such as credit card information.
Actualization: The buyer gets custody of the resource and the provider gets
custody of payment (Payment, Resource).
Post-actualization: The provider offers warranty-related services (Post-sale
services).
108
The figure below models this business template in an e3 value model.
Figure 21. Template 4: e3 value model for an immediate settlement-oriented, authorization-independent transaction type
In the above figure, we model both obligation to payment (Right to payment) and the custody transfer of the money (Payment). However as mentioned in the previous section, the provider may get custody of money from a
third actor such as a bank. The same is true for the resource transfers regarding the offering of the resource.
5.4 Summary
In this chapter, we have analyzed value-based business collaborations and
thereby we have defined four possible types of business transactions. Using
them, we have proposed a set of templates that span the five major phases in
business collaboration as defined by the Open-edi initiative.
Two primary types of business collaborations; Future Settlement-Oriented
and Immediate Settlement-Oriented, are identified in this chapter. For each
of them, we have also identified a set of attributes based on the goals of collaborations. Considering these attributes and the collaboration types, the four
basic transaction templates have been derived. In addition to this, these four
transaction types are investigated along different phases of business collaboration such as planning, identification, negotiation, actualization and postactualization to identify possible values exchanged in each phase. The results
are modeled using an e3 value business modeling approach.
From a business modeling point of view, a modeler will desire to be able
to design business transactions by choosing a particular scenario from a set
of scenarios and applying it to the intended business. Obtaining a smaller
number of mandatory business transaction scenarios and distinguishing them
from each other has been identified as a problem (ISO/IEC, 2002). In this
chapter, we suggest overcoming this by proposing two types of major business transactions and combining them based on attributes such as product
dependency and authorization dependency. The resulting set consists of four
types of business transactions that a modeler can choose from and apply it to
109
the intended business. Thereby, the proposed classification of business transactions can benefit the designing of business models by systematizing the
identification of business transactions. It will also help them to create new
and innovative business models that extend the assortment of the exchanged
resources, thereby improving the economic performance of a network of
actors in business collaborations.
110
6 Designing Explorative Business Models by
Analyzing Business Collaborations
6. 1 Introduction
Designing a business model involves identifying different actors, transactions and resources exchanged by them. In the work presented in this chapter, we use the goal-aligned business model designed in Chapter 4 as the
basis for designing an enhanced business model. The focus of Chapter 4 was
to analyze the intentions of business actors and to propose a set of templates
to design goal model and transformation rules to identify business model
components from the means in the goal model. Therefore, the goal-aligned
business modeling method in Chapter 4 was not aimed at grouping different
resource transfers to business transactions. Hence, from a business transaction point of view, the completeness of the business model obtained at the
end may be highly dependent on the experience of goal and business model
designers.
As such, in this chapter, we set our focus to discuss how to use the different transaction types proposed in Chapter 5 to improve business modeling.
Figure 22 depicts the business model designing process. The figure depicts
two possible modeling scenarios:
• A business modeler may start from a business case (business information) to identify different business transactions and further explore them
along planning, identification, negotiation, actualization and postactualization phases to identify resources and resource transfers and design a business model. The curved left arrow (solid) depicts this path
(see Figure 22).
• A business modeler may use a goal-aligned business model as proposed
in Chapter 4 to identify different business transactions and further explore them along the business collaboration phases mentioned above to
design an explorative business model. This scenario is shown by curved
right arrows (dashed) which link business information to the goalaligned business model and finally to the method for designing an explorative business model (see Figure 22).
111
Figure 22. Overview of the modeling scenarios
The method that we present in this chapter involves steps to identify business transaction with different focuses and resources exchanged by these
transactions. The chapter is organized as follows: Section 6.2 presents an
overview of the designing process and defines additional concepts required
by the designing process. Next, the method for designing an explorative
business model is presented. Finally, we discuss the application of the method by using the eye-care health case scenario.
6.2 Overview of the business model designing process
In this section, we give an overview of the designing process by briefly introducing and defining the concepts that will be used in the method in Section 6.3. The designing of an explorative business model involves using different results that we have already obtained in previous chapters. We utilize
the goal-aligned business model obtained in Figure 15 to identify different
transactions based on the transaction types presented in Chapter 5. The obtained transaction will be further investigated to elicit resources along different phases; planning, identification, negotiation, actualization and postactualization. For elicitation of resources, we consider both extrinsic and
intrinsic aspects of consumer value (Holbrook, 1999). Considering extrinsic
aspects, we first investigate each business transaction along the planning,
identification, negotiation, actualization and post-actualization phases to
identify economic resources (i.e resources). To do this, we utilize the resources as defined in Chapter 3. Once the resources are identified consider112
ing the extrinsic aspect, we go through the business collaboration phases
again and consider intrinsic aspects to identify zero or more resources. For
this, we utilize internal values that are discussed below.
Figure 23. Overview of the designing process
6.2.1 Eliciting resources across Open-edi business collaboration
phases
In business modeling, the actualization phase is often considered when determining the exchange of resources in a business constellation (Gailly et al.,
2008). Thereby, it is reasonable to argue that business models designed
based on a goal-aligned business modeling method will include resource
transfers pertaining to the actualization phase. However, from a business
modeling perspective, the activities performed in the other phases of a business collaboration can create value to consumers by transferring resources
other than the major resources. Thereby, it is important that the whole business collaboration life cycle is considered in eliciting resources. To elicit
resources across these phases, we utilize categories of resources discussed in
Section 3.2 and their relationship to different phases as discussed in Section
5.3.
113
6.2.2 Eliciting resources considering internal values
Once the resources are elicited along different phases considering extrinsic
aspects, we next consider intrinsic aspects and use internal values to elicit
zero or more resources.
An internal value is a particular way of providing a resource. It highlights
a way of delivering the resource that steers or influences the choices to be
made during different stages of a business collaboration. Internal values are
not objects but they are features whose existence are dependent on some
object. An example for this could be the convenience attached to the home
delivery of a product. They cannot be directly transferred between actors. It
is not meaningful to talk about legal rights on these values, neither it is possible to transfer any of these resources from one actor to another. Internal
values are also identified as playing an important role in modeling the business strategy of a company (Heinrich & Winter, 2004). There, internal values are considered as success factors describing how different sales
processes facilitate the value proposition of a company. Additionally, internal values can be classified as ends in themselves, or as the instruments for
other purposes. For instance, someone might desire more knowledge without
any intention to use it in a particular way. Someone else might desire knowledge in order to make money through lecturing or other knowledge services,
i.e. they use knowledge as an instrument for producing some other resource.
The first categorization of internal values fits into the intrinsic value category of Holbrook’s classification (Holbrook, 1999).
Internal values can also be used to distinguish a firm from its competitors.
Weigand et al. (2007) have analyzed the role of these as second order values
alongside the core resources exchanged between actors. They propose a list
of such values and argue that these internal values can be characterized in a
more precise way by utilizing such a list. They further state that at the end
these internal values can lead to identifying features that a firm can use to
distinguish itself from its competitors.
In the following, we utilize the following tentative list of internal values
as proposed in Weigand et al. (2007):
•
•
•
speed
responsiveness
customizability
•
•
•
convenience
safety
reliability
We believe that the above list may be extended and standardized. Theoretical frameworks such as multiple-item scale for measuring service quality
(SERVQUAL) (Parasuraman, Zeithaml & Berry, 1988) could be used in this
regard. In the following, we discuss the possible use of the above outlined
internal values in the planning, identification, negotiation, actualization and
post-actualization phases discussed in Section 2.4.2.
114
• In the planning phase, an actor typically provides informative-type resources, such as catalogues. For a consumer, time and effort in obtaining
this information are two important factors. Therefore, in a planning
phase, the medium of information delivery such as electronic or print; the
quality of information such as relevance, up-to-date and correctness are
the vital aspects which give a consumer a pleasant experience. As such,
we identify convenience and reliability as the internal values related to
the planning phase collaborations between actors.
• Similar to the planning phase, the identification phase also regards the
exchange of information among actors. This is basically to establish a literal link between actors. Thus, for the provider, what is most important in
this phase is the reliability of the information that he gets from the consumer. Therefore, in this phase, we examine the identified resources
against the internal value reliability to investigate the correctness of the
information, in order to examine if there are additional resources that may
support the desired internal value. This could lead to the derivation of
new resources, for example, the verification of consumer accreditation
correctness, provided by a third actor.
• In the negotiation phase, actors exchange different rights on the resources. Customizability, safety and reliability are identified as internal
values in this phase. The customizability addresses the issue of being
able to agree on different forms of a resource such as game CDs and their
delivery, or home delivery, etc. In the context of agreements, the latter
two internal values mainly concern the issues related to risks, an aspect
that we do not consider in this chapter.
• In the actualization phase, actors carry out the custody transfers of the
resources agreed in the negotiation phase. We identify safety and reliability as internal values here. The former concerns the risks of custody transfers, while the latter concerns whether the custody transfers are according
to the agreements in the negotiation phase.
• In the post-actualization phase we identify responsiveness as the major
internal value. In this phase a consumer should be able to obtain the postsale services that they need to be able to effectively consume the resources that they have purchased. For example, a provider should be willing to provide additional services such as replacements, or repairs for the
sold objects.
From the REA and e3 value modeling perspectives, resources that we discussed above are similar to economic resources and value objects. However,
internal values are unsupported, they are used as a basis for identifying additional resources in a given business model that may fulfill the requirements
for internal values.
115
6.3 Method for designing a business model
The designing of an explorative business model involves different steps
where the business modeler identifies different transactions from the goalaligned base business model and further investigates each transaction along
different phases: planning, identification, negotiation, actualization and postactualization to identify more resource transfers.
In the remaining sections, we present steps involved in the business model designing process. We conclude the section by providing a detailed discussion of the process using the eye-care health case used as the running
example.
6.3.1 Identifying business transactions
In the first step, the business modeler identifies the business transactions by
analyzing and refining the resource transfers of all the involved actors, as
elicited in the base business model. The business modeler performs the tasks
by pursuing two guidelines:
Guideline 1: Analyze reciprocal resource transfers in the business model, to
identify business transactions.
The given guideline concerns the exchange of resources between actors.
Here the main concern is on identifying transactions with immediate settlement-orientation. These transactions may include potential alternatives for
the transfer of the same resource. As an example, a patient may get from a
primary care provider either a full treatment, or an initial treatment followed
by a referral to an eye-care specialist.
Guideline 2: For each transaction elicited using Guideline 1, consider addition of transactions concerning establishments of commitments between that
mandatory precede actual resource offerings.
This guideline concerns the identification of future settlement-oriented,
product-dependent transactions. The goal of the transactions defined here is
to establish commitments for the transactions identified in Guideline 1.
These transactions concern one-time activities pertaining to the establishment of the right to future transactions where the right is exercised a number
of times over some period of time. Examples of such transactions could be
user profile creations at Amazon.com, residents’ registration at healthcare
centers, and so forth. Transactions concerning the establishment of commitments can either be done by the actors who provide the main resources, or
they can be carried out by the actors not visible in the base business model.
116
For example, the resident registration can either be done by the primary care
provider itself, or it can be carried out by some other actor.
Here, commitments are established by means of exchanging information
between actors regarding some resource type. They could be later fulfilled
by different transactions or they may never be fulfilled meaning for example,
a resident never take treatments from his registered healthcare center.
6.3.2 Identifying resources
In this step, the business modeler examines the transactions identified in the
above step to identify additional resources and resource transfers according
to the following guidelines:
Guideline 3: For each transaction identified using Guidelines 1 and 2:
a. Identify resources that are to be exchanged in the planning, identification, negotiation, actualization and post-actualization phases of a given
transaction.
b. Identify internal values that are to be exchanged in the planning, identification, negotiation, actualization and post-actualization phases of a
given transaction. Thereby elicit the resources that will realize the
wanted internal values.
Thus, in the first outlined task, the modeler should analyze every transaction across the whole collaboration life cycle (i.e. from planning to postactualization) to identify additional resources. This is needed as the given
transactions are identified for the actualization phase only. In the second
task, we examine the elicited resources across business collaboration phases
to identify zero or more additional resources.
To elicit resources, the modeler should consider possible resource types
associated with business transactions that have been discussed in Section
3.2. In addition to that, he should consider the analysis of internal values that
we have presented in Section 6.2.2 to elicit additional resources that will
realize the identified internal values. The modeler will then use the information about business transactions, actors and resources to improve the goalaligned business model obtained by applying the goal-aligned business modeling method.
Utilizing the classification of resources and discussion on internal values
presented, and the goal-aligned business model in Figure 15 as an input,
below we illustrate the application of the method presented in this section.
6.4 Application of the method to the eye-care case
In this section, application of the method presented in Section 6.2 is illustrated using the eye-care health case as the business scenario. To obtain the
117
final business model, we further investigate the goal-aligned business model
(Figure 15) to identify additional business transactions, actors and resources.
6.4.1 Identifying business transactions in the eye-care case
The goal-aligned business model in Figure 15 in Chapter 5 models four
business transactions. These transactions are depicted in Figure 24. Resource
and
model alternatives offerings of the retransfers in interfaces
source treatment by the primary care (i.e. treatment without referral to specialist care and with referral to specialist care). Interfaces
and
models
resource transfers related to the offering of advance treatment by the healthcare specialist to patient and resource transfers related to procuring information by the primary care physician from the healthcare knowledge center.
Figure 24. A goal-aligned business model for the eye-care case showing different
business transactions
Utilizing Guideline 1, we elicit the following transactions for the goalaligned business model in the above figure. Considering the alternatives in
and , we consider following cases for the offering of the
the interface
resource treatment by a primary care physician to a patient.
• Primary care physician offers full treatment to a patient.
118
•
Primary care physician offers basic treatment and refers patient to a
healthcare specialist.
From the above cases, it is clear that there are three types of resources offered by the primary care physician: full treatment, initial treatment and referral. Considering these resources, we identify FullTreatment, InitialTreatment transactions associated with the interfaces
and . Interface
concerns the offering of advance treatment by a healthcare specialist to a patient
referred by a primary care physician. Thereby, we identify the transaction
AdvanceTreatment connected to interface . Concerning the offering of the
resources information about healthcare specialists and knowledge on symptoms and diseases, we identify the transaction InformationProvisioning associated with Interface . Below, we summarize the transactions identified
utilizing Guideline 1.
a. FullTreatment: for providing a full treatment by the primary care provider to the patient. (Interface )
b. InitialTreatment: for providing an initial treatment and referral by the
primary care provider to the patient and healthcare specialist. (Interface )
c. AdvanceTreatment: for providing an advance treatment by the healthcare specialist. (Interface )
d. InformationProvisioning: for providing information by the health services office. (Interface )
Next, each of the above transactions, is investigated to identify additional
business transactions that concern the establishment commitments (future
settlement-oriented, product-dependent). Thereby, the following transactions
are identified utilizing Guideline 2.
e. PatientRegistration: for registering patients by the health services office (concerning transaction FullTreatment and InitialTreatment).
f. SpecialistRegistration: for providing registration to the healthcare
specialists and providing healthcare specialist information to the primary care physician (concerning the transaction AdvanceTreatment).
g. PrimaryCareRegistration: registering primary care centers by the
health services office to establish commitment concerning the transaction InformationProvisioning.
6.4.2 Identifying resources in the eye-care case
Below, we explore several transactions elicited in Section 6.3.1, along the
planning, identification, negotiation, actualization and post-actualization
phases, to identify the resources as proposed in Guideline 3. For each set of
transactions identified there, we first search for resources across the collaboration phases (Guideline 3a). Then we consider internal values along these
phases and derive more resources (Guideline 3b).
119
In this section, we only explore FullTreatment and PatientRegistration
transactions as identified in Section 6.3.1. A discussion on identifying resources and internal values, for the rest of the transactions, is available in
Appendix A.
In the table below, we report the results when applying Guideline 3a for
FullTreatment and PatientRegistration transactions.
Table 4. Economic values of FullTreatment and PatientRegistration transactions
Post-actualization
Actualization
Negotiation
Identification
Planning
FullTreatment
PatientRegistration
Commitment for the treatment The Registration Office offers Regishas been already established in tration service information
the PatientRegistration trans- Resource: RegistrationServiceInfo
action and hence no resources
are identified in here.
Patients provide Accreditation Patients provide personal information
information to primary care.
to register them to with the primary
care center.
Resource: Accreditation
Resource: PersonalInformation
Primary care offers
Right2timeSlot to the patients.
patients offer Right to payment
to the primary care.
Resources: Right2TimeSlot,
Right2Payment
Primary care offers Full treatment to the patients.
Resource: FullTreatment
Patients get Right2Services.
Resource: Right2TreatmentServices
Registration Office sends Information
bulletin to the registered patients
Resource: InformationBulletin
Primary care offers Timeslot to No resources could be identified in
post health examination.
the post-actualization phase of this
primary care offers Post-health transaction.
examination to the patients.
Resources: TimeSlot2PostHealth Examination,
PostHealthExamination.
For the transactions FullTreatment and PatientRegistration, we have identified a number of new economic values (i.e. resources) in the table above.
These are valued for their usage as a utility to achieve some goals of any of
the actors involved in the transaction. For example, the RegistrationServi-
120
ceInfo has a useful value to the Patient since it provides the Patient with an
opportunity to get information about the healthcare services offered by primary care centers and to understand whether or not the Patient should register at a particular primary care center.
Next we re-examine each of the elicited resources, to identify internal
values, along all the five phases.
In the planning phase of PatientRegistration, the Patient may find it is
convenient if the Primary care offers registration service information in different formats such as e-catalogues and printed catalogues. Hence, we derive
a new resources: eCatalogue and PrintedCatalogue as different choices that
replace a previously identified resource: RegistrationServiceInfo. For the
transaction FullTreatment, no new resources are identified in the planning
phase.
In the Identification phase of the transaction FullTreatment, the accreditation of the patient should be checked against the original registration data.
Therefore, considering the reliability of information provided by the patient,
we derive a resource, PatientData to be received by the Primary care from
the Health services office. This resource is offered within the transaction
InformationProvisioning, in addition to the resources already provided by
the Health services office to the Primary care physician.
Considering the customizability in the negotiation phase, we derive new
resources: Right2CancelAppoinment regarding the transaction, FullTreatment and Right2UpdatePersonalInfo regarding the transaction PatientRegistration other than ones already derived in the table above.
In the actualization phase, considering fast and reliability, we identify
economic values: eDeliveryOfInformationBulletin for the transaction PatientRegistration. In addition to the already identified economic values for the
FullTreatment transaction, we derive HomeVisitService4Elders as the other
option of the resource FullTreatment. That is, they are not offered simultaneously.
Considering the intrinsic values in the post-actualization phase for the
transactions FullTreatment, and PatientRegistration, we could not derive
new resources other than the ones we have already identified.
In Figure 25, we summarize and depict the excerpt-business model including the complete set of resource transfers for transactions FullTreatment
and PatientRegistration, as elicited using our method. Thereby, the given
business model includes the resource transfers that originate from the exploration of the collaboration phases, as well as from the consideration of the
consumer-related internal values.
121
Figure 25. e3 value model for the PatientRegistration and FullTreatment transactions
6.4.3 Designing a business model for the eye-care case
In this section, we integrate the business model fragments presented above
and in Appendix A to create the business model for the eye-care case (see
Appendix A for the business model fragments that concern the business
transactions that are not discussed in Section 6.3.2). In comparison with the
goal-aligned business model given in Figure 15, and by applying the method
presented in Section 6.2, new actors as well as new resource offerings are
identified. The final business model in Figure 26 below, models four actors,
the Patients, the Primary care, the Specialist Care Center, and the Health
Services Office.
122
Figure 26. e3 value business model for the eye-care case
In Figure 26, the Patients first register themselves at the Health service office and this is modeled by transaction . The Health service office records
specialist care centers and this is shown in transaction in the model.
The provisioning of a full treatment by the Primary care physician is
modeled by the previously explored transaction FullTreatment and this
transaction is marked as
in Figure 26. The transaction InitialTreatment
between the Patients and the Primary care is depicted with .
The transaction AdvanceTreatment between the Patients and the Specialist is shown by transaction .
Finally, the provisioning of the information services (InformationProvisioning) to the Primary care by the Health services office and the transaction
associated with the registration for required for it (PrimaryCareRegistration)
is modeled by transactions and
respectively.
123
6.5 Summary
To summarize, in this chapter, we have presented a method for designing an
explorative business model. The method uses the goal-aligned business
model in Chapter 5 as an input to identify business transactions. To elicit
business transactions, we have considered the classification of business
transactions proposed in Chapter 6. These business transactions are further
explored to elicit resources across the business collaboration lifespan and for
this we have utilized resources, resource transfers and internal values discussed in Chapter 4.
As emphasized in the beginning of the study, the practical relevance of
an explorative business model such as the one exemplified in Figure 26 is
twofold: the business modeler can use the obtained business model, for indepth analysis of its viability from both business and economic perspectives.
The system analyst can use the model to gain a detailed understanding of
enterprise collaboration models, to identify e-services, for instance.
124
7 Using Business Models for Designing EServices
Since the emergence of the Internet, enterprises have opened their core functions to customers, suppliers, business partners and financial institutions.
The intensive growth of the World Wide Web has created opportunities for
all kinds of enterprises to make their value offerings available to consumers
as e-services. An example of this is the proliferation of bookstores on the
Web that let Internet users browse their catalogues, place orders, and make
payments.
A problem common to actors participating in such collaborations is to
identify what offerings they should make available as e-services for others.
Identifying such value offerings lies primarily on the business model level.
In previous chapters, we have discussed exploring business collaborations
using business models. A business model clarifies the roles played by different stakeholders of a given business scenario and the relationships between
them. It also captures vital information regarding the creation and distribution of economic resources between the stakeholders.
From the technical perspective, Web services have become a common
technology for modeling interactions of Web applications. So far, the development of Web services has focused on structural and operational aspects.
As a result, the designing process lacks the visibility of business functionality. To make the process more business-oriented we need to start the designing of service-oriented applications from a higher level of abstraction. Raising the level of abstraction to separate business specifications from implementation details is a well-established trend in system development and is
one of the main goals of MDA (Kleppe et al., 2003).
The MDA process typically involves the creation of three different types
of models. Computational Independent Model (CIM) is used to describe
business level information, independent of technology considerations. This
model is further refined to a Platform Independent Model (PIM), which specifies a high-level design of an IT system. Finally, the PIM is transformed
into a Platform Specific Model (PSM), which adds the technology details
necessary for the implementation on a specific software platform.
One of the major issues in the MDA discipline is the choice of model
types to be used for CIMs and PIMs. In this chapter, we explain how business models can be used at the CIM level, to provide a clear and a declara125
tive foundation for identifying the business services of an enterprise. Exploring a business model across a whole collaboration life cycle, i.e. starting
from planning to post-actualization, enables us to describe the entire enterprise-wide business service portfolio within the CIM. At the same level,
process models are used to describe the behavior these business services. To
enable mapping of the elicited top-level business services further to the eservices at the PIM level, we rely on the use of UML profiles that provide a
standard way to set a model focus on a specific architectural style, such as in
this case – service-oriented. Conceptualized in this way, the method that we
propose is able to support the integration and alignment of economic value
propositions of the collaborating business actors with the ICT realizations,
formed using Web services technology. The method has a practical relevance for exploring the enterprise models in more depth from the business
perspective, in order to identify e-services and design systems accordingly.
7.1 Designing e-services on the MDA basis
E-service design has so far been mainly focused on operational aspects such
as the standardization of message transfers and the coordination of e-services
leaving business aspects less concerned. With the influence of networking
facilities growing, the use of e-services across organizational boundaries has
evolved from point-wise uses to large scale uses. This large scale usage of eservices justifies the focus on aspects mentioned above since it has become
important to concern the coordination of e-services to form an e-network
(Piccinelli & Stammers, 2001) and to standardize message exchange mechanisms between them. It equally highlights the importance of analyzing
business aspects to identify economically viable e-services.
E-services that are not derived from business values could be hard to understand and implement. As such business organizations are increasingly
interested in assessing the economic viability and alignment to underlying
business values of e-services before implementing them as e-services. Thereby recent research in the area (e.g. Gordijn et al., 2009; Andersson et al.,
2008; Baida et al., 2005; Zlatev et al., 2004) are more focused on obtaining
constructive results by analyzing business values in the beginning of the
process for identifying and designing service-oriented software solutions.
Much research in e-service design has recognized (Baida et al., 2005; Andersson et al., 2008) that in multi-enterprise business environments, modeling and managing business knowledge of each enterprise plays an important
role in identifying competitive resource offerings to their customers and
realizing them as e-services. Thereby, they have identified two classes of
services as important in realizing such multi-enterprise business scenarios.
They are:
126
• High-level services (business services) that businesses wish to offer to
their customers. These are identified on the basis of business models.
• Low-level services that realize these business services, as e-services
which will be further refined into processes and tasks. These e-services
are typically implemented using Web services.
This relationship between top and low level services (e-services) has resulted in the introduction of a top-down style approach for designing and
implementing e-services considering strategic business aspects of deriving
value to consumers.
The work presented in this chapter proposes an MDA-based approach for
designing business-oriented e-services which may be implemented using
Web services or related technology. We utilize business models and process
models to define the CIM level model in our approach.
In the remaining parts of this section, we give a brief overview of business models, process models and their uses as CIM level models in MDAbased approaches.
7.1.1 Modeling business activities – business models
Business models abstract away operational and procedural aspects of business activities. As mentioned in previous chapters, business models focus on
modeling the what of the business. They typically describe business actors,
different objects of value exchanged between them, different levels of collaborations between them, etc. Business models are also used as a tool to evaluate the economic viability of value constellations. They are often used as a
basis for identifying economically viable candidates for implementing as eservices. In such contexts business models support analysis of consumer
needs, mapping them to different activities and quantifying resource transfers between different actors. We have discussed business modeling in detail, especially in Chapter 2, and therefore avoid more detailed discussion in
this section.
A number of business modeling techniques are available for designing
business models. They are REA, e3 value and BMO (for more information,
please refer to Chapter 2). For the illustration purposes of the work presented
in this chapter, we use the well-established business modeling technique e3
value to model the CIM. Since the focus in this chapter is to identify candidates for e-services, we primarily focus on the collaboration space between
actors and thereby to identify various resource transfers and associated resources. In this regard we use the enhanced business model obtained considering planning, identification, negotiation, actualization and postactualization, at the end of the previous chapter as the basis for modeling and
identifying e-services.
127
7.1.2 Modeling operational aspects of business – process
models
Process models are used to describe operational aspects of business specifying how activities are structured and channeled from one to another to fulfill
the goals of some business activities. They typically describe the procedural
and communication aspects of a business activity (e.g. order management)
articulating various flows like control, data and message flows between the
different process model components. Therefore business process is primarily
defined as the specific ordering of activities across time and space with a
clearly defined starting point, end point, inputs and outputs (Davenport,
1992).
Process models are designed using various languages and notions.
Among them, the most popular are the Business Process Modeling Notation
(BPMN) (White, 2006) and UML Activity Diagrams (UML, 2009). In particular MDA recommends UML as the modeling standard in MDA-based
approaches. UML enables modeling at different abstraction levels and thus
facilitates much needed interoperability between different models used in
MDA approaches.
Modeling business processes involves the consideration of different aspects. Curtis, Kellner & Over (1992) propose four perspectives: organizational, functional, informational and behavioral should be considered in designing business processes.
The organizational perspective describes who is responsible for which
business activities. Hence the central focus here is on the notion of the actor,
for instance, an organization unit, or a software system. UML 2 uses the
partition notion to depict this perspective.
The functional perspective concerns the composition of activities and
their execution. An activity can be either atomic, or composite. These notions correspond to activities and actions in UML 2 notation, respectively.
The informational perspective concerns the resources produced and manipulated by a process. A resource can be products, services and informational objects such as data. UML 2 offers the object node to depict the informational aspect.
The behavioral perspective specifies the different control flows that describe how activities are executed. UML 2 provides a number of controlflow components such as decision and merge nodes, fork-and-join node,
start and end nodes, and so forth.
We utilize the described framework to elicit the components of process
models that the business modeler should consider as mandatory when modeling the service behavior in CIM and PIM, to enable a complete elicitation
of that behavior.
128
7.2 Designing e-services using business models
In this section, we describe a methodology for identifying and designing eservices starting from a business model. The method essentially consists of
different steps where we develop CIM and PIM models. Below, we discuss
the different steps involved in designing CIM and PIM models.
7.2.1 Creating business-oriented (CIM) models
Generating a CIM model is a two step process where we consider business
and behavioral aspects of the top-level business services to be designed. In
the following, we discuss each step in detail.
Step 1: We identify business transactions and design the business model to
identify candidates for business services.
In this step, we utilize the business modeling design methodology discussed in Chapter 7 to design a business model that will be used to identify
candidates for e-services. Individual resource transfers in the designed business model will become candidates for designing e-services. It was observed
in the previous chapter that exploring the transactions from the base model
along the five phases, results in the identification of new economic events
and resources for supporting the planning and identification activities, negotiating and establishment of the rights on the core resources, delivering the
custody of the resources, and finally, the activities for facilitating successful
resource utilization.
Often, when offering a resource, an actor expects some other resource(s)
as compensation. This relationship can be observed among the events performed in the planning, identification and negotiation phases of a business
collaboration, where an event acquiring some resource is unavoidably accompanied by the other event giving away another resource. For instance, to
get a product catalogue, a consumer must identify himself by providing his
contact details. As another example, a negotiation cannot be completed before both involved actors agree on the rights to the resources that they will
provide to each other.
Therefore, reciprocal events in each of the above phases, give rise to one
business service. However, following the negotiation, due to a variety of
business agreements alternatives, it may be possible for the actors to give
away certain resources without getting compensation at the same time. A
typical example could be, a seller agreeing with a buyer to paying for certain
goods after the goods are delivered. That is, in the actualization and postactualization phases, it is possible to refine the granularity of business services to correspond to single economic events, such as payment, or delivery
performed in those phases.
129
At the end of Step 1 all the desired resources exchanges are explored and
depicted in the business model and the business services for their provisioning are elicited. These high-level services elicited during Step 1 are of composite nature and hence their behaviors could be modeled by decomposing
them down to several lower level activities.
Step 2: Where we design the process models to describe the behavior of the
business services elicited in Step 1.
In this step, we focus on deriving processes from the business model
created in Step 1. Each process identified here corresponds to a single business service elicited in the previous step and designed without regarding any
technological concerns. Also when designing processes, the designer should
use his domain knowledge and properly reflect on organizational, functional,
informational and behavioral modeling perspectives to get a complete
process model.
At the end of this step, the high-level services, drawn from the business
model, are well-described exploring their behaviors using the corresponding
process models. These process models are documented using UML 2 Activity Diagrams.
To summarize, the CIM model that we propose in this chapter consists of
a business model and process models. The business model is designed considering the whole collaboration life cycle from which the business services
are drawn out. The process models depict the behavior of each of the business services and are designed from four perspectives: organizational, functional, informational and behavioral.
7.2.2 Creating system-oriented (PIM) models
The business and process models designed in Step 1 and Step 2 are used as
the complete CIM model input for creating a UML-based PIM.
Obtaining PIM from a CIM involves defining transformation rules to derive the former from the latter. We use UML 2 Profile for Software Services,
proposed by IBM (Johnston, 2005) to capture map information at CIM-level
down to PIM-level.
We utilize UML 2 Activity Diagrams to specify data and control flows
between different activities in a e-service. Hence, the PIM will be a system
model describing e-service structure and its behavior. In the next section we
explain, in detail, how different components of PIM are derived. We also
define the rules for mapping out these components from the CIM-level.
Figure 27 below depicts the conceptual model of the UML 2 Profile for
Software Services. Primarily, the model consists of stereotyped extensions of
different elements of UML 2.0 meta-model such as Classes, Classifiers, Col-
130
laborations, etc. In the table below, we briefly explain the major elements of
the profile that we use in this chapter.
Table 5. Different elements of UML 2 Profile for Software Services.
Partition
Service
Provider
Service
Consumer
Service
The Partition element defines the responsibility or system
boundaries for offering different services.
A Service Provider provides one or more Services.
A Service Consumer element in the profile is used as a
classifier to identify consumers of a service.
The Service element acts as a name tag of a service offered
by the Service Provider, where the actual definition of what it
offers, is given with the Service Specification.
The Service Specification element identifies the service
Service
Specification interface, that is, a set of operations. The element can also
specify the order of invocation of the operations associated
with it, using the protocol state machine (i.e. Protocol).
The Operation element defines the atomic functionalities of
Operation
the Service element.
The Message element represents the containers for the
Message
service input or output data.
The Message Attachment is associated to Message element as
Message
a property of the Message element. For example, a Message
Attachment
element may contain product details while the images of
these products are delivered as Message Attachment
elements.
The Service Gateway considers the openness of the service,
Service
by denoting the Service Specification elements available to
Gateway
access within a partition.
131
Figure 27. UML 2.0 profile diagram (Johnston, 2005)
In our approach, certain profile elements are not modeled explicitly in
PIM. Service Collaboration and Service Channel contain the details belonging to a platform specific level and therefore, we omit the use of these elements. As for the service Protocol element, we define it using the UML 2
activity diagram, to define a complete orchestration for every identified eservice. In this way, the final PIM will reflect a system model including both
structural (i.e. service contract) and behavioral aspects of e-services.
Defining CIM to PIM transformations
The transformation from CIM to PIM essentially involves a number of highlevel rules that map the components from the CIM, i.e. from the business
model and the process models, to the elements in the PIM model. In the
mapping process we have taken functional, organizational, behavioral and
informational aspects into consideration and classified the mapping rules
into these perspectives; we present the transformation rules, below.
132
Organisational Aspect: The organizational aspect is concerned with the
distribution of the responsibilities for executing e-services at a system level.
The provider of a business service is considered as the principal actor.
Organizational
Aspect
Rule 1
a. Each non-principal actor partition in the CIM/Process
Model is mapped to a partition in the PIM to host the
interaction activities of the principal actor toward that
actor.
b. The partition of the principal actor is refined to the
partitions that will include information retrieval/storing
activities, by determining the providers of these activities.
Design considerations: for every added Partition element type in
PIM/Service Profile by following Rule 1, the elements of type Service Provider, Service, Service Specification and Service Gateway (optionally) are
created.
Functional Aspect: the second rule concerns the transformation of the
activities from CIM to PIM:
Rule 2
a. Every activity in the CIM/Process Model concerning the
interactions between partitions is transformed to a send,
receive, or send-receive operation.
Functional Aspect
b. Additional send, receive, send-receive operations are
created for every new partition identified in Rule 1, to
model the interaction activities for that partitions.
c. An activity modeled in CIM is decomposed, or
aggregated to conform to the functions of the existing
systems (for example, “receive customer profile” in a
CIM may be decomposed to “receive customer contact”
and “receive customer history” in a PIM, if those
information are provided by different existing system
services).
Activities that concern assignments (i.e. “delegations”), rules and
calculations will be mapped only to the PIM/Service Behavior, as
such activities do not correspond to service operations. Those
activities are the part of the internal process system logic of the
principal actor.
133
Design considerations: following Rule 2, operation elements are added in
PIM/Service Profile;
Informational Aspect: the third rule concerns the transformation of
information resources from CIM to PIM.
Rule 3
Informational
Aspect
a. Every information resource is transformed to a message.
b. If an information resource (artifact) is supported
differently due to changes in the functional aspect (Rule
2), then the resource granularity will be changed
(decomposed, or aggregated).
The system modeler should derive information objects in parallel to the
functional aspect discussed above.
Design considerations: information objects in CIM are mapped to Message
and, optionally to, Message Attachment elements in PIM/Service Profile,
according to the described rule.
Behavioural Aspect: the fourth rule concerns the transformation of controlflow from CIM to PIM.
The Service Profile model does not support modeling of control-flow between different operations, messages, etc. As such, we use CIM and PIM
level activity diagrams to define the behavioral aspect of a business or electronic service. Generally, the flow of the PIM level activity diagram will
follow the flow of the CIM level activity diagram. Yet, the flow may be adjusted to suit the identification of new activities and messages.
Behavioral
Aspect
Rule 4
134
The control flow as given in the CIM/Process Model is reused in
PIM/Service Behavior Model; the flow is refined to support the
orderings of new elements, as added with Rule 2 (functional
aspect). The internal, flow-related activities, such as rules and
assignments, are mapped from CIM (rules), or created at this
stage (assignments).
From the PIM to a PSM
Finally, the obtained PIM is transformed into a PSM, which includes the
details necessary for getting an executable software model. The primary aim
of this chapter was to give an approach for transforming a value-oriented
CIM to a service-oriented PIM. For that reason, in this section we will give
only brief guidelines for how a PSM can be obtained from the proposed
PIM.
The PIM structure as we have defined it in the previous sections includes
both the structural and behavioral aspects of e-services. As such, the model
supports creating executable service-oriented solutions including service
static specification and coordination. For instance, in case the Web services
are the target technology platform, then the given PIM will be automatically
converted to:
a. WSDL documents, from the UML Profile class diagram, for specifying the Web service interfaces, operations and messages (for more details, the reader is referred to IBM UML 2 Profile for Software Services (Johnston, 2005); and
b. to a workflow-like specification, such as BPEL (OASIS, 2007), from
the UML activity diagram, for getting the sequences of invocations of
the obtained Web services, i.e. their operations.
In our running example, the PIM/Service Profile model (see Figure 30)
can be used to create WSDL specifications for two e-services: Contract
Communication and Contract Data. For instance, the Message and Service
Specification profile elements associated with these e-services can be
mapped to WSDL Message types and PortTypes respectively. An excerpt of
WSDL specification for the e-service Contract Communication as obtained
from the PIM, will look as follows.
<wsdl:message name=" accreditation">
<wsdl:part name="accreditationInfo" type="someType"/>
</wsdl:message>
<wsdl:message name="scheduleTerms">
<wsdl:part name="scheduleContractTerms" type="xsd:string"/>
</wsdl:message>
…
…
<wsdl:portType name="treatmentContractInterface ">
<wsdl:operation name=" receivePatientAccreditation">
<wsdl:input message=" accreditation"/>
……
……
</wsdl:operation>
</wsdl:portType>
135
The BPEL specification for the PSM can be obtained by mapping the PIM
models and their constituent components to different BPEL elements. For
instance, the UML activity diagram is mapped to the BPEL control-flow,
Operations in the class diagram to the BPEL activities, Partition elements to
the BPEL partner declarations, etc. Below, we exemplify a BPEL specification that will be obtained for the previously explored top e-service Establish
Contract. In particular, the UML class diagram in Figure 30 in Section 7.3 is
converted to BPEL process declaration. The control flow and the activities in
the UML activity diagram from Figure 31 in Section 7.3 define the BPEL
activity flow.
<process name="establishContract">
targetNameSpace=http://abc.com/simpleContractProcessing
xmlns:lns="http://contracts.org/wsdl/contract-establishment"
…………………
…………………/>
<partners>
<partner name="patientManager"
serviceLinkType="lns:contractApproveLinkType"
myRole="approver"/>
<partner name="dataService"
…………
………/>
<partners>
<sequence>
<receive name="receiveAccreditationInfo" partner="patientManager"
portType="…"
operation="receivePatientAccreditation"
……/>
</receive>
<invoke name="invokeScheduleManager"
partner="scheduleManager"
portType="…"
……/>
</invoke>
……
……
</sequence>
<process>
The automatic transformations from UML models to BPEL specifications
are discussed and proposed in a number of papers; for more details the reader is referred to White (2006) and Amsden et al. (2003).
136
7.3 Application of the method to the eye-care case
In this section, we use the eye-care health case example, to explore the method presented in the previous section. We set our focus on providing service-oriented solutions to the primary care physician. As such, we concentrate on business transactions between the primary care physician, their
healthcare associates and patients in Figure 26. The figure below depicts a
simplified version of the business model in Figure 26 which shows the business transactions that happen between the primary care physician, their
healthcare associates and the patient,
Figure 28. An excerpt of the eye-care business model showing the primary care
physician and their business transactions
Figure 28 depicts six business transactions between a primary care physician, their associates and patients. FullTreatment ( ), InitialTreatment
( ),InformationProvisioning ( ), PrimaryCareRegistration ( ). To explore the e-service design method presented in this chapter, we consider the
transaction; FullTreatment. The selected transaction will be explored along
planning, identification and negotiation phases to identify business services
that can be offered online, i.e. e-services. Finally, we show the application of
137
the method, exploring one of the e-services identified along above phases
and creating CIM, and PIM models by utilizing the transformation rules
presented in Section 7.2.2.
Developing CIM for the eye-care case
Following the method for creating the CIM, and using the FullTreatment
transaction as explained in the previous section, we continue in this section
with a deeper explanation of how the method is applied.
Application of Step 1: Creating CIM/Business Model
In this step, we utilize the business model in Figure 28 as the starting point
for identifying high-level services. As stated in the beginning of this section,
we consider the transaction FullTreatment to identify business services. In
the table below, we summarize, resource transfers of the transaction
FullTreatment across planning, identification, negotiation, actualization and
post-actualization phases.
Table 6. Summary of resource transfers across different phases of the business
transaction FullTreatment.
Actualization Negotiation
Identification Planning
Resource transfers
138
Commitment for the treatment has been already established in the PatientRegistration transaction and hence no resources identified in here.
Patient provides Accreditation information to Primary care physician
Primary care physician provides Access to health services to Patient.
Resource: Accreditation, Access2HealthServices
Resource transfers: Obtain Accreditation (Patient), Provide
Access2HealthServices (Primary care physician)
Primary care physician offers Right2timeSlot to Patient.
Primary care physician offers Right2CancelApoinment to Patient.
Patient offers Right to Payment to Primary care physician.
Resources: Right2TimeSlot, Right2Payment, Right2CancelAppoinment
Resource transfers: Obtain Right2Payment (Patient), Provide
Right2TimeSlot (Primary care physician), Provide
Right2CancelAppoinment (Primary care physician)
Patient gets Full treatment
Primary care physician gets Fee
Resource: FullTreatment, Fee
Resource transfers: Provide FullTreatment (Primary care physician),
Obtain Fee (Patient)
Post-actualization
Primary care offers Timeslot to post health examination to Patient.
Primary care offers Post-health examination to Patient.
Resources: TimeSlot2PostHealthExamination, PostHealthExam.
Resource transfers: Provide TimeSlot2PostHealtExamination (Primary
care physician), Provide PostHealthExamination (Primary care physician)
Following the argumentation given in the previous section, in Step 1, by
default, resource transfers in every phase in Table 6 correspond to a single
business service. In the identification and negotiation phases, an actor to
obtain a resource should give away some other resource(s). Therefore, the
reciprocal events in the identification and negotiation phases give rise to
single business service in each phase. For instance, the Primary care gets
Accreditation from the Patient and in return provides Access to Health Services. However, following the negotiation phase, as argued previously, since
the contract has been already established, single resource transfers in actualization and post-actualization phases can give rise to a set of single business
services. For example, Primary care can provide treatment first and later
receive the Fee from the Patient.
Therefore, from the above business model, we identify the following
business services.
• Access Provisioning which corresponds to the resource transfers Obtain
Accreditation – Provide Access to Health Services, in the identification
phase.
• Treatment Scheduling which corresponds to the resource transfers Provide Right to Time Slot and Provide Right to Cancel appointment – Obtain Right to Payment in the negotiation phase.
• Treatment Provisioning, and Payment Handling which corresponds to the
resource transfers provide full treatment, and obtain fee, respectively in
the actualization phase.
• Post Treatment Management which corresponds to the resource transfers
provide time slot to post-health examination and provide post-health examination, respectively, in the post-actualization phase.
Application of Step 2: Creating CIM/Process Models
In this step, we consider the resource transfers; Provide Right to Time Slot
and Provide Right to Cancel appointment – Obtain Right to Payment, which
form the business service Treatment Scheduling. Aligning with Step 1, the
process model in this step shall be created from the Primary care physician’s
perspective.
Considering the organizational, functional, behavioral and informational
aspects, by using the UML 2 Activity Diagram notation, the process model
corresponding to the Treatment Scheduling is created. Examining the organizational perspective, the business modeler will create two Basic UML 2
139
partitions: Primary care and Patient. Then, the modeler will explore the two
major tasks in this service: obtaining accreditation from a Patient and sending back a treatment schedule. The modeler will then, concerning the functional perspective, create an orchestration of the activities as depicted in
Figure 29 (using UML 2 activities and control-flow elements). Also, he will
use an informational perspective to model message/document exchanges
within the process using UML 2 objects. In particular, the process begins
when the Primary care provider receives the accreditation from the Patient.
This information will then be checked against the registration information to
see whether the Patient is registered with the Primary care physician or not.
If the Patient is registered with the Primary care physician, then his registration data will be checked to see whether the Patient has an existing treatment
time allocation. Based on these, the Primary care provider decides whether
to offer the Patient a treatment schedule, offer him a cancellation of the existing time schedule or accept of the Patient’s request.
140
Figure 29. UML activity diagram exploring the details of the Treatment Scheduling
service
Developing PIM for the eye-care case
The business model and the process models, developed in the previous section, together define the CIM that will be used as the input to create the
UML-based PIM. To make the transformation from CIM to PIM, we will
utilize the transformation rules and the UML Profile presented in Section
7.2.2.
In this section, we will use the transformation rules 1–5 to illustrate the
derivation of the elements in the PIM from the CIM created in the previous
section for the service Treatment Scheduling and in the negotiation phase of
the transaction FullTreatment.
141
Application of Rule 1:
• (Rule 1,a) The partition Patient in the CIM-level activity diagram is
mapped to the PatientManagement partition element in the PIM-level
class diagram. The PatientManagement partition will include the
interactions of the Primary care provider to the Patient. For this
partition, a Service Provider, Service, Service Specification and Service
Gateway elements are created and named PatientManager,
and
TreatmentContract,
TreatmentContractInterface
PatientManagementGateway. The Gateway element is added to define
that the service specification is accessible outside its hosting partition.
(see Figure 30).
•
(Rule 1,b) The ScheduleManagement partition is added to host the
information retrieval activities of the Primary care provider, such as
Check if the patient has a registration in CIM-level activity diagram in
Figure 29. As in the previous example, for the created partition, Service
Provider, Service and Service Specification and Gateway elements are
added, as depicted in Figure 30.
Application of Rule 2:
• (Rule 2, a) The activity “Provide accreditation” from the CIM-level
activity diagram (see Figure 29) is mapped to the Operation element
“receivePatientAccreditation” within the TreatmentContractInterface
(Figure 30). In the same way, “Get cancellation details and terms”,
“Get schedule and terms”, “Provide schedule acceptance/rejection”
,“Provide cancellation acceptance/rejection” and “Get cancellation
notification” activities from the CIM-level activity diagram are mapped
to
“sendCancellationTerms”,
“sendScheduleAndTerms”,
“receiveConsent4Schedule”,
“receiveConsent4Cancellation”
and
“sendcancellationNotice” within the TreatmentContractInterface. The
activities “Get patient accreditation”, “Offer schedule proposal and
terms”, “Get schedule acceptance/rejection”, “Get cancellation
acceptance/rejection” and “Offer cancellation confirmation” of the
Primary care partition in the CIM-level activity diagram are mapped to
“sendPatientAccreditation”,
“receiveAvailableTimeSlots”,
“sendPatientTimeSlotSelection”,
“sendCancellationInformation”
elements within the scheduleInterface of the scheduleManagement
partition (Figure 30).
•
142
(Rule 2, b) The Operation elements “receiveRegistrationStatus”,
“sendRegistrationInformation”,
“receivePatientStatus”,
“sendPatientInformation”, “receiveCancellationConfirmation” and
“receiveContractDetails” within scheduleInterface are added (Figure
30). These Operation elements facilitate the interaction between
different send and receive Operation elements already introduced in the
respective partitions. For instance, the Operation element
“receiveRegistrationStatus” receives information regarding a Patient
registration status based on the information requested by the send
Operation element “sendPatientAccreditation”. Similarly, the Operation
elements, “sendRegistrationInformation”, and “receivePatientStatus”
models interaction activities by requesting information regarding a
Patient's status (i.e. whether the Patient has a existing treatment
schedule or not) and receiving the result.
•
(Rule 2, c) The activity element Provide contract/registration status in
the CIM-level activity diagram is decomposed to Operation element
“sendContract” within the treatmentContractInterface (Figure 30).
Registration status information, to be sent to Patients who are not
registered with Primary care, is received by the Operation element
receiveRegistrationStatus in Rule 2, b, above.
The activities “Check if the patient has a registration” and “check if the
patient has a treatment schedule” in the CIM-level activity diagram, that
concern assignments, are mapped to “selectPlayerInformation” and “selectPatientAndRegistrationInformation” in the PIM/Service Behavior
(Figure 31). Additional activities such as “selectPatientInformation”, prepareRegistrationNotice, etc (see Figure 31) are created to delegate messages
between send and receive activities of “patientManagement” and “scheduleManagement” partitions.
Application of Rule 3:
• (Rule 3, a) The information resource “Accreditation”, “Cancellation
details/Terms”, “Schedule/Terms”, “Schedule decision”, “Cancellation
decision”, and “Cancellation notice” from the CIM (see Figure 29) is
mapped to the Message element “accreditation”, “cancellationTerms”,
“schedule/Terms”, “consentForSchedule”, “consentForCancellation”,
and “cancellationNotice” (Figure 30).
• (Rule 3, b) Considering the decomposition of the activity Provide
contract/termination notification in the functional aspects in Rule 2(c),
the information resource “Contract/termination notice” from the CIMlevel activity diagram (see Figure 29) is decomposed to the Message
elements “contract” and “registrationStatus” in PIM/Service Profile
(Figure 30). Considering the introduction of Operation elements
“receivePatientStatus”,
“sendRegistrationInformation”,
143
“sendPatientInformation”, “receiveCancellationConfirmation” and
“receiveContractDetails” within scheduleInterface in Rule 2(b), new
Message
elements
“patientStatus”,
“registrationInformation”,
“patientInformation”, “cancellationConfirmation”, “contractDetails”.
Additionally, considering the identification of different assignment
elements, to delegate messages between send and receive operations
between different partitions, in Rule 2, the Message elements
“timeSlots”,
“patientTimeSlotSelection”,
“scheduleCancellationInformation” are identified and associated to
Operation
elements
“receiveAvailableTimeSlots”,
“sendPatientTimeSlotSelection”, and “sendCancellationInformation”.
Application of Rule 4:
The control-and data flow of the CIM Activity Diagram (AD) (i.e. the
behavioral aspect) and the created service partitions (organizational aspect),
service operations (functional aspect), and the messages (informational
aspect) in the PIM class diagram model, are used to create a PIM/Service
Behavior model (see Figure 31). In the PIM/Service Behavior model, the
flow is generally defined by the CIM-level activity diagram in Figure 29. It
depicts the behavioral details for the e-service Treatment Scheduling.
144
145
Figure 30. Service model class diagram
PIM/Service Behavior model in Figure 31 explores the service coordination
aspect while the PIM/Service Profile model in the Figure 30 above defines
the service contract for Treatment Scheduling.
Figure 31.UML activity diagram at PIM level
Similarly, CIM and PIM level models can be created for other elicited business services related to the transaction FullTreatment.
7.4 Summary
In this chapter, we have introduced a MDA-based method for designing eservices, which may be implemented using Web services or some other related technology.
We propose the use of a business model at CIM level to identify economically viable business services and a UML based process model to define the
arrangement of the events of the identified business services. The business
model and process models corresponding to the high-level services identified
146
at the CIM level is converted to e-services in PIM level through a set of
transformations. The proposed method offers several advantages.
First it provides an explorative basis for identifying business services illustrating a high level description of a whole business scenario in a single and
easily understandable view. Here we have shown that the business modeler
can elicit an explorative business service portfolio that enables the provisioning of economic values along five phases: planning, identification, negotiation, actualization and post-actualization of the business collaboration. This
business model is further elaborated by the modeling behavior of every business service elicited in there and these two models form the CIM. The CIM
model will then be transformed into a high-level system model, i.e. PIM
which describes the elements and its structuring of e-services. This PIM
level system model can be converted to an executable service specification
and service coordination, using for instance, Web service technology.
The benefit of the proposed method is twofold. First, it enables a systematic and explorative identification of value-founded e-services, which improves the overall performance of a network of actors in the business collaborations. Secondly, the method describes a clear and straightforward approach for the development of e-services and their coordination. Using the
MDA as a cornerstone, the method enables traceability of low-level executable e-services toward economic value offerings, thus justifying the economic
viability of these e-services.
147
148
8 Conclusion and Discussion
In this section, we first discuss the research results achieved in relation to the
problems and goals that we presented in Sections 1.2 and 1.3. Next we briefly compare the artifacts that we have presented in this thesis with similar
approaches for business modeling to improve e-business application designing. Finally, based on the Hevner (2004) framework for design science research, we discuss different steps involved in the research work presented in
this thesis.
8.1 Concluding Remarks
In this thesis, we address the problem of designing business models to improve e-business solutions designing.
Business models are used to represent a high-level view of resource offering and producing activities of an organization. Thereby, it is important that
intentions of business stakeholders and different business environments are
taken into account when designing business models as well as e-services.
Goal models are often used to capture stakeholder intentions and map them
down to operational aspects such as concrete activities that realize the goals.
In recent years, developing a business strategy that calls for an IT strategy
has been identified as a critical success factor for any organization. As a
consequence organizations are looking to develop distinctive competencies,
more often by means of IT, that enable them to add value in a unique way to
outshine the competition. To identify what competencies are needed and
how to differentiate them from others, companies need a comprehensive
understanding of what their business partners and customers expect from
them or more precisely, stakeholder intentions. Such an understanding will
help them to adjust their value creation process to offer value-added resource
offerings to their customers. Thus it can be argued that business models,
which are used as a part of capturing requirements for e-business applications development, should reflect on the intentions of different business
stakeholders. An important consequence of such a reflection will be traceability between business strategies and system components thus giving better
alignment between e-business applications and business strategies. While
stakeholder intentions can be thought of as describing an internal view by
defining actions performed by actors towards the others, it is equally impor149
tant to consider business environments or the external shared space where
the business collaborations between actors occur. The business collaboration
space defines the business transactions between business actors and their
underlying resources offerings. From a service exploration point of view, the
consideration of stakeholder intentions or more precisely, goals, and business collaborations is important to identify a strategically-aligned and economically sustainable set of e-services.
Considering the above aspects, we have defined the basic research question for this work as: How to design business models and e-services whilst
taking into account stakeholder intentions and business environments? The
basic research question was addressed by decomposing it down to three specific questions. These specific research questions concerned:
• designing business models considering goal models;
• designing business models business collaborations; and
• using business models to design economically viable e-services.
Novel artifacts in the form of constructs and methods were developed
concerning research problems discussed in Section 1.2. Below, we discuss
the proposed artifacts in relation to the research problems in Section 1.2.
As a basis for business modeling, important concepts such as resource
and resource transfers were investigated. Considering resources, we had
identified economic resources and internal values as being important concepts in business modeling. Considering the transfer of resources between
different business stakeholders, we made a distinction between different
components, such as rights, custody and evidence documents.
• The problem of designing a goal-aligned business model was addressed
by means of analyzing, different business notions and goal and business
alignment. A set of instruments for designing a business model were presented considering goal-business alignment. Goal and business model are
linked to each other through the notion of means. To facilitate means
formulation, a number of templates have been proposed. These templates
represent the basic activities of an enterprise: acquiring, providing, producing, or maintaining resources.
Figure 32. Research results in relation to Problem 1 and Goal 1
150
• To address the second research problem, business modeling was further
facilitated by classifying business transactions that happen between business stakeholders, into four different types. These transactions were identified considering different goals that a business collaboration should
have. Furthermore, a method was proposed, to investigate these transactions further, to identify more resource transfers along different phases of
a business collaboration such as planning, identification, negotiation, actualization and post-actualization phases proposed in (ISO/IEC, 2004).
This process of identifying resource transfers across the business collaboration lifespan should provide the business modeler with additional instruments to extend the goal-aligned business model, considering the aspects that may have not been covered in the formulation of means templates. The method could also be used to design business models without
the goal-aligned business model as an input.
The figure below summarizes the research results achieved in relation to
the research Problem 1 and Goal 1, presented in Section 1.1 and 1.2, respectively.
Figure 33. Research results in relation to the second research problem and goal.
• The problem of designing e-services was addressed by proposing a designing methodology that uses the business model as the basis for identifying economically viable e-services. Here, we proposed a model driven
approach for designing e-services. The designing methodology uses several instruments (see Figure 34) that address the third research problem
and goal. The proposed method uses a goal and collaboration-aligned
business model as the explorative basis for designing business-oriented
model – CIM for identifying a services portfolio that is aligned to business strategies. Additionally, a set of guidelines for mapping businessoriented (CIM-level) models to system-oriented (PIM-level) models were
proposed.
151
Figure 34. Research results in relation to the third goal and research problem
The business model design methodology and e-service design methodology provides a modeler with a useful set of tools. Firstly, to design a detailed
business model that is aligned to the intentions of various business stakeholders. It also provides a systematic approach for designing a business
model considering goals and different types of business transactions. The
designed business model provides an explorative basis for identifying an eservices portfolio that is clearly aligned to business strategies. As such the
business and e-service design methods provide important instruments for
designing strategically-aligned business models and economically sustainable e-services. Figure 35 depicts the overall research results in relation to the
goals of the thesis.
152
Figure 35. Overview of research results in relation to thesis goals
8.2 Comparison to similar research
In this section, we briefly discuss work similar to our research work. These
comparisons are done to the evaluate goal-aligned business modeling method in Chapter 4, and the method for designing e-services using business
models presented in Chapter 7.
Goal-based business modeling method
The Business-oriented Approach Supporting Web Services Idea Exploration
(BASSIE) approach proposed in Raadt et al. (2005) uses the qualitative aspect of strategic goal modeling to complement the quantitative aspect of the
e3 value business modeling approach. The BASSIE approach proposes to
design a goal model that represents the current situation of an enterprise. The
153
designed goal model is then used to develop a business model for the enterprise. In general, we follow the same line. This means that, the business
modeling method introduced in Chapter 4 first considers the strategic interests of actors and then designs the business model that describes the resources offerings between them. However, there are fundamental differences
between the BASSIE approach and the goal-aligned business modeling method presented in Chapter 4. One of the key differences is that the business
modeling method presented in Chapter 4 provides templates for formulating
goals and means while the BASSIE approach does not. On the positive side,
the use of business notion-based design templates to formulate means
enables different designers to express different goals and means in a similar
way. As such the uniform goal model creation can be regarded as an advantage of the method presented in Chapter 4. Besides means templates, our
method in Chapter 4 also defines the alternatives associated with each means
template and actions that will realize them at the business level. These
should help business modelers to arrive at major design decisions about what
design choices they have to make and how these choices will affect the realization of means. This will enable the creation of uniform business models.
The BASSIE approach provides a set of guidelines for mapping a goal model to a business model. Since BASSIE does not use templates to assist goal
modeling, the guidelines used to transform the goal model to the business
model are defined at a general level. For example, taking a goal model component such as an actor and mapping it to an actor in a business model. Thereby, they take different forms than the transformation rules that we have
defined in Chapter 4.
Business model-based e-service design method
The methods presented in Gordijn et al. (2009) and Cherbakov et al. (2005)
show the importance of considering consumer needs and their fulfillment
aspects when designing e-services. The e-service design method in Gordijn
et al. (2009) uses three different requirements viewpoints: value, process and
information systems viewpoints. The purpose of the value viewpoint is to
design a business model taking the consumers’ needs into consideration.
This viewpoint has been used as the starting point to obtain a profitable portfolio of e-services. The process viewpoint is used to decompose interaction
between different actors into processes. This viewpoint elaborates the relationship between the consumers’ needs identified in the value viewpoint and
the different tasks required to realize them. Finally, the information systems
viewpoint defines workflow specifications for e-services elicited in the value
viewpoint by utilizing the task decomposition in the process viewpoint.
However, the approach does not provide clear information on how the information regarding resource transfers on the value viewpoint is used in the
process view point. These viewpoints are abstractly related to each other by
eliciting processes at the process viewpoint for consumer needs elicited in
154
the value viewpoint. Unlike the use of consumer needs to elicit processes by
Gordijn et al. (2009), we investigate resource transfers across the planning,
identification, negotiation, actualization and post-actualization phases of
business collaborations. The reciprocal resource transfers obtained are
mapped to business services which are further elaborated using business
processes. We also propose mappings from business-oriented models to system-oriented models by considering organizational, functional, informational
and behavioral perspectives in process designing. Both approaches use UML
profiles to obtain high-level non-technical-oriented models describing, for
instance work-flow type specifications for obtained e-services. Another important distinction is that, in contrast is that, even being model driven, Gordijn et al. (2009), does not define models and model transformations as recommended by the MDA discipline.
On the business level, Cherbakov et al. (2005) uses a Component Business Model (CBM) to define business functions that can be implemented as,
for instance, e-services. CBM is used by IBM as a method to create business
models as an organized collection of business components. The IBM approach for realizing a service-oriented enterprise in Cherbakov et al. (2005),
uses the CBM framework for modeling business by organizing business
activities into components. Each of these components is ideally supported by
IT-enabled services. The method uses SOMA to map business model components to e-services that realize the associated business functions. The similarities between the e-service design method that we present in Chapter 7
and the methods discussed above, are that they all identify the importance of
considering the business aspect to obtain an economically sustainable set of
e-services. They all use business models as a point of departure to elicit
business services which are further elaborated to elicit and define processes
that realize them. For the differences, in the method presented in Chapter 7,
we follow the MDA-based approach. However, even being model-oriented,
the above mentioned proposal does not define models and model transformations. Also, in IBM CBMs components seem to represent aggregated business functions such as product sales which may include a number of resource transfers. In contrast we elicit atomic resource transfers across the
planning, identification, negotiation, actualization and post-actualization
phases of each business transaction between actors. This facilitates traceability meaning that elicited e-services can be traced back to their corresponding
economic resource transfers at the business level.
MDA principles are used ina number of research studies to propose methods to design e-services. Typically, these approaches use PIM as a starting
point for designing MDA-based solutions for developing e-services. For
instance, Johnston (2005), López-Sanz, Acuña, Cuesta, & Marcos (2008)
and Amsden et al. (2003), use UML profiles to define technologyindependent models at PIM level as the starting point of designing MDA
based e-services. Some other studies have used models at CIM level as the
155
starting point for designing MDA-based e-service design approaches. For
instance, approaches in Rosen (2003), Vidales, Sánchez, Fermoso & Aguilar
(2008), and Kherraf, Lefebvre & Suryn (2008) add a business perspective to
the development process using business process models for developing CIMlevel models and mapping them further to PIM-level. Since these process
models focus on the operational aspects of business, the aforementioned
approaches do not describe the association between the designed e-services
and business activities in general.
8.3 Discussion about the research process
Hevner et al. (2004) present a conceptual framework that could be used to
evaluate the design science research for its usefulness, applicability and the
effectiveness in the problem domain. It consists of seven guidelines that
should be satisfied by effective design science research. In the following we
analyze our work according to these guidelines. More information about
these guidelines can be obtained from Hevner et al. (2004).
Guideline 1: Design as an artefact
“Design-Science research must produce a viable artefact in the form of a
construct, a model, a method or an instantiation” (Hevner et al., 2004, pp.
83).
In this thesis, we propose novel methods for designing business models and
e-services.
For business modeling, the methods provide: identification of components
of a resource transfer, templates to formulate goals and means using business
notions, transformation rules to identify business model components to build
a business model based on the goal model, a structured way of identifying
resource exchanges across the business collaboration lifespan.
For e-service design, we employ an MDA-based approach which uses a
business modeling method mentioned above at CIM-level and a set of transformation rules to transform it to a PIM.
Thereby, there are two clearly identifiable artifacts created in this research
work. They are: methods for designing business models and a method for
designing e-services.
Guideline 2: Problem Relevance
“The objective of design-science research is to develop technology-based
solutions to important and relevant business problems” (Hevner et al., 2004,
pp. 83).
With inter-organizational e-commerce growing rapidly, there is an increased
interest in designing business models and e-services as prominent activities
in e-business application development. However, there is still lack of under156
standing about how business goals and strategies should be aligned with
business models and how business models could be used to design eservices. One issue with the current business modeling methods is that they
often consider core resource exchanges such as goods for money and do not
consider the other forms of resources exchanged between collaborating parties during the collaboration lifespan. Yet, these other resource exchanges
need to be considered in business modeling as they could identify vital information needed for e-business application development, for instance providing some clues about how business processes should be designed. From
an e-service designing point of view, business models should be used as a
means for designing economically sustainable e-services. As it was for business modeling, this is an area that has captured the interest of researchers.
However, when business models are not designed in an explorative way by
considering all the resource exchanges across the entire business collaboration lifespan, it is often difficult to obtain a comprehensive business service
portfolio.
These are the very relevant problems that we address by this research.
Guideline 3: Design evaluation
“The utility, quality, and efficacy of a design artifact must be rigorously
demonstrated via well-executed evaluation methods” (Hevner et al., 2004,
pp. 83).
As explained in Hevner et al. (2004), evaluation is a crucial component in a
research process. It proves whether or not a developed artifact is actually
useful to solve the problem that it is intended to solve.
We have shown the applicability of the proposed methods through a descriptive method using a scenario-based evaluation and informed arguments.
Two business scenarios, from different domains are, used for the evaluation: the MMOG case and Swedish health case from the REMS project
(Henkel et al., 2007). The healthcare business case from the REMS project is
used to evaluate the business modeling methods whereas the MMOG case is
used to evaluate the method for e-service design. The first hand information
of the researchers involved in the REMS project were used in the evaluation
process. In addition to that, various research publications were used to obtain the details of the business cases as mentioned above. Naturally, the
business requirements of the two business scenarios were different. For instance, the MMOG business scenario had more online transfer of resources
offerings between actors. The REMS healthcare case involved more physical
interaction between actors to exchange resources such as treatments. These
differences helped us to evaluate the artifacts by showing their applicability
in different domains. In terms of complexity, both these cases had variety of
resource exchanges that represented all the basic types of business collaborations that we have identified in Chapter 5. As such, these business cases
157
helped us show, to what extent, the methods proposed in the thesis could
help business modelers and service designers to think beyond traditional
producer-consumer roles and design innovative e-business solutions by exposing the multiplicity of resource types and flows between different activities that interact with each other.
In addition to using business scenarios to evaluate the obtained artifacts,
we have used informed argument to illustrate the effectiveness of the solutions proposed in the thesis for the problems and goals presented in Chapter
1. In Section 8.1, we compare the business modeling and e-service design
methods to similar research studies, from both academia and industry.
Guideline 4: Research contributions
“Effective design-science research must provide clear and verifiable contributions in the areas of the design artifact, design foundations, and/or design
methodologies” (Hevner et al., 2004, pp. 83).
The main contributions of this research include methods for designing business models and e-services.
Concerning designing business models, we propose:
a. a way of using goal models as a basis for designing business models;
b. a classification of business transactions;
c. a way of designing business models by identifying resource transfers
across an entire business collaboration lifespan, i.e. from initial planning activities to possible post- sale activities.
Regarding e-service design, we propose a model-driven approach:
a. which uses business models at the CIM level;
b. which uses a set of transformation rules to obtain high-level system
models (PIM) that specifies structure and behavior of the e-services.
Guideline 5: Research rigor
“Design-science research relies upon the application of rigorous methods in
both the construction and evaluation of the design artifact” (Hevner et al.,
2004, pp. 83).
The work presented in this thesis is grounded on well-established theories,
standards and modeling approaches. For instance, the reference ontology is
designed based on the analysis of three well-established ontologies: REA;
BMO; and e3 value. Among them, REA has its origins in accounting theory
where every transaction is seen as either an increasing or decreasing resource
of an organization. The BMO has its roots in the Balance Scorecard approach (Kaplan & Nortan, 1996) and business management literature such as
Markides (1999). The e3 value ontology is based on the value-based requirements’ engineering theories such as Holbrook (1999) and Porter (1998).
Other than the above sources, other well-established business management
frameworks such as the Porter value chain (1998), consumer value frame158
work by Morris Holbrook (1999), goal modeling approaches such as BMM
(2007) and standards for business collaboration modeling such as ISO Openedi 15944-1(ISO/IEC, 2002) and 15944-4 (ISO/IEC, 2007) serve as foundations for the work presented in this thesis. The presented artifacts are evaluated using a descriptive business scenario to demonstrate their utilitarian
values.
Guideline 6: Design as a search process
“The search for an effective artifact requires utilizing available means to
reach desired ends while satisfying laws in the problem environment”
(Hevner et a.l, 2004, pp. 83).
The solutions to the problems of designing business models and e-services,
mentioned in Chapter 1, are determined through several steps. First, existing
theories of consumer value creation and three well-established business
modeling frameworks are used to identify different components of a resource transfer: rights transfer (of resource), custody transfer (of resource)
and documentary evidence transfer, between actors involved in a business
collaboration. In the second step, these results are used to develop methods
to design business models. Here, goal and collaboration aspects are considered to develop methods to design business models. Existing goal modeling
techniques, standards regarding business collaborations are used in the development of the methods. Important results in the second step include: a set
of design templates for formulating goals and means in terms of business
modeling notions, a classification of business transactions that are used to
develop methods for designing business models presented in this thesis. The
capabilities of existing approaches for business modeling are extended by
means of capturing and using goals to develop business models and extending their ability to capture resources across the entire business collaboration
lifespan. The latter is an important requirement for developing a e-service
design method. The search process for these design methods is iterative in
the sense that the results are fine-grained over several research publications
and the capabilities of the methods are presented using several examples.
Guideline 7: Communication of research
“Design-science research must be presented effectively both to technologyoriented as well as management-oriented audiences” (Hevner et al., 2004,
pp. 83).
Two types of artifacts are presented in this thesis. They include the methods
for designing business models, which focuses on the exchange of different
values in a networked business constellation and a method for designing eservices. These methods are communicated to both types of audiences by
using well-established graphical value modeling tools to exemplify the methods proposed and highlighting the advantages of the methods. Also, the
research results were presented at leading scientific research forums.
159
8.4 Future research directions
In this thesis, we have presented a set of artifacts aimed at improving ebusiness solutions design. They include methods for business model design
and e-service design. In business model design methods, we have set focus
on defining a business model by aligning business goals with business models and identifying resource transfers along different phases of a business
collaboration life-cycle. In the MDA based e-service design method, we
have set focus on defining a business-oriented model (CIM) which elicits
value-oriented business services utilizing business model designed based on
aforementioned business model design methods. This business-oriented
model (CIM) is further transformed into system-oriented model (PIM) by
capturing e-service structure and behavior. Considering these aspects of
business modeling and e-service design, we see number of possible directions for future research. These directions are briefly discussed below.
- Goal-business alignment: in regard to goal-aligned business model design, assessment of sufficiency of the means templates would be of high
importance. This will enable us to see if the means templates proposed in
this thesis are sufficient for modeling courses of actions in any business
environment. Such an assessment can be achieved by, for instance, performing an industry-wide survey considering how business actors in different domains define their strategic interests. In addition to that, it is also
worthwhile to investigate how elicitation of goals can be structured. This
may be achieved, for instance, considering aspects such as customer,
competitor and capability analysis and developing contribution models to
make formulation of goals easier. As an example, a contribution model
designed based on a customer perspective may define a number of activities that a business wishes to carry out on one dimension and then mapping these activities to internal resources (e.g. knowledge) of customers
on the other dimension.
- Business-driven e-service exploration: identification of customer needs
and mapping them to the activities required to fulfill those needs is of
high importance to develop a complete and easily understandable business-oriented model (CIM). One way to achieve this is by creating a
business-oriented model (CIM) with separate layers that illustrate how
generic value chain activity of a business is decomposed to specific resource exchanges and to finally elicit business services along different
phases of that business collaboration life-span. In addition to that, capturing business semantics at the business-oriented model (CIM) level and
mapping them to the system-oriented model (PIM) level is another important aspect to consider in future research work. One way to achieve
this is to use meta-data model for developing business-oriented model
(CIM). By doing so we should be able to achieve smoother transformation between different models.
160
Finally, in order to perform a comprehensive validation, the business model
design methods and e-service design method should be applied to industrybased complex case studies.
161
162
References
Afuah, A. & Tucci, C. (2001). Internet Business Models and Strategies. Boston: McGraw-Hill.
Amsden, J. & Gardner, T., Griffin, C. & Iyengar, S. (2003). Draft UML 1.4
Profile for Automated Business Processes with a Mapping to BPEL 1.0.
Retrieved
April
10,
2009,
from
http://www.ibm.com/developerworks/rational/library/content/04April/3
103/3103_UMLProfileForBusinessProcesses1.1.pdf
Anderssson, B., Johannesson, P. & Zdravkovic, J. (2008). Aligning Goals
and Services through Goal and Business Modeling. International Journal of Information Systems and e-Business Management (ISEB), 7, 143169.
Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S. & Holley,
K. (2008). SOMA: A method for developing service-oriented solutions.
IBM Systems Journal, 47(3), 377-396.
Avison D., Lau F., Myers M. & Nielsen P. A. (1999). Action Research.
Communications of the ACM, 42(1), 94–97.
Baida, Z., Gordijn, J., Saele, H., Akkermans, H. & Morch, A. (2005). An
Ontological Approach for Eliciting and Understanding Needs in eServices. In: O. Pastor J.F. Cunha (Ed.), 17th Conference on Advanced
Information Systems Engineering, (LNCS Vol. 3520 pp. 400-414). Berlin: Springer-Verlag.
Braet, O. & Ballon, P. (2007). Business Model Scenarios for Remote Management. Journal of Theoretical and Applied Electronic Commerce Research, 13(3), 62-79.
Business Rules Group (BRG) (2007). Business Motivation Model. Retrieved
February
14,
2009
from
http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf
Cherbakov, L., Galambos, G., Harishankar, R., Kalyana, S., & Rackham, G.
(2005). Impact of Service Orientation at the Business Level. IBM Systems Journal, 44(4), 653-668.
Chesbrough, H. & Rosenbloom, R.S. (2002). The Role of the Business Model in Capturing Value from Innovation: Evidence from Xerox Corporation's Technology Spin-Off Companies. Industrial and Corporate
Change, 11(3),529-555.
Christensen, E., Curbera, F., Meredith, G. & Weerawarana. S. (2001). Web
Services Description Language (WSDL) 1.1. Technical Report, World
163
Wide Web Consortium, Retrieved June 5, 2009 from:
http://www.w3.org/TR/wsdl
Currie, W. (2004). Value Creation from E-Business Models. ButterworthHeinemann. Oxford, UK.
Curtis B., Kellner M. & Over, J. (1992). Process Modeling. Communication
of the ACM, 35(9), 75-90.
Dardenne A., Lamsweerde A. & Fickas S. (1993). Goal-Directed Requirements Acquisition. Science of Computer Programming, 20(1-2), 3-50.
Davenport, T. (1992). Process Innovation: Reengineering work through
information technology. Harvard Business School.
Derzsi, Z. & Gordijn, J. (2006). A Framework for Business/IT Alignment in
Networked Value Constellations. In Yves Pigneur, Carson Woo (Ed),
International Workshop on Business/IT Alignment and Interoperability
(co-located with CAISE 2006), (CEUR Vol 237, pp. 219-226), CEUR
Workshop Proceedings.
Fox, M.S. (1992). The TOVE Project: Towards A Common-Sense Model of
the Enterprise. Enterprise Integration Laboratory Technical Report. Retrieved February 10, 2009, from http://www.eil.utoronto.ca/enterprisemodelling/papers/fox-tove-uofttr92.pdf
Gailly, F., España, S., Poels, G., Pastor, O. (2008). Integrating Business
Domain Ontologies with Early Requirements Modelling, (LNCS Vol.
5232, pp. 282-291). Berlin: Springer-Verlag.
Gailly, F. & Poels, G. (2007). Towards Ontology-Driven Information Systems: Redesign and Formalization of the REA Ontology. In Witold Abramowicz (Ed.), 10th International Conference, Business Information
Systems, (LNCS Vol 4439, pp. 245–259), Berlin: Springer-Verlag.
Geerts, G. & McCarthy, W.E. (2005). The Ontological Foundation of REA
Enterprise Information Systems. Retrieved May 20, 2009 from
www.msu.edu/~mccarth4/Alabama.doc
Gordijn J., Akkermans, H. & van Vliet, H. (2000). Business Modelling is
not Process Modelling. In Stephen W. Liddle, Heinrich C. Mayr &
Bernhard Thalheim (Ed.), Conceptual Modeling for E-Business and the
Web, ECOMO 2000, (LNCS Vol. 1921, pp. 40-51), Berlin: SpringerVerlag.
Gordijn, J. (2002). Value-based Requirements Engineering - Exploring Innovative e-Commerce Ideas [PhD. Thesis] Vrije University, Netherlands.
Gordijn, J., Osterwalder, A. & Pigneur, Y. (2005). Comparing two Business
Model Ontologies for Designing E-Business and Value Constellations.
In Proceedings of the 18th Bled Conference, Retrieved April 10, 2009
from http://www.bledconference.org/proceedings.nsf/Proc2005Resear
ch?OpenPage
Gordijn J., Yu, E. & van der Raadt B. (2006a). E-Services Design Using i*
and e3 Value Modeling. IEEE Software, 23(3), 26-33.
164
Gordijn, J., Petit, M. & Wieringa, R. (2006b). Understanding Business Strategies of Networked Value Constellations Using Goal- and Value Modeling. 14th IEEE International Requirements Engineering Conference
(RE'06), (pp. 126-138), USA: IEEE Computer Society.
Gordijn, J. van Eck, P. & Wieringa, R. (2009). Requirements Engineering
Techniques for e-Services. In Georgakopoulos, D., & Papazoglou, M.P.
(Ed.), Service-Oriented Computing: Cooperative Information Systems
series (pp. 331-352). Cambridge, MA: MIT Press.
Guba, E.G. & Lincoln, Y.S. (1994). Competing Paradigms in Qualitative
Research. In N.K. Denzin & Y.S. Lincoln (Ed.), Handbook of Qualitative Research (pp. 105-117). Thousand Oaks: Sage.
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 199-220.
Heinrich, B. & Winter, R. (2004). A Strategy Modelling Technique for Financial Services. The European IS Profession in the Global Networking
Environment, In Proceedings of the 12th European Conference on Information Systems, Retrieved
April 15, 2009 from
http://www.informatik.uni-trier.de/~ley/db/conf/ecis/ecis2004.html
Henkel M., Johannesson P, Perjons E. & Zdravkovic J. (2007). Value and
Goal Driven Design of e-Services. International Conference on EBusiness Engineering (ICEBE 2007), (pp. 295-303), Washington, USA:
IEEE Computer Society.
Hevner, A.R., March, S.T., Park, J. & Ram, S. (2004). Design Science in
Information Systems Research. MIS Quarterly, 28(1), 75-106.
High, R., Kinder, S. & Graham, S. (2005). IBM’s SOA Foundation: An Architectural Introduction and Overview, Version 1.0. IBM. Retrieved
April
4,
2009
from
http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/
ws-soa-whitepaper.pdf
Holbrook, M. B. (1999) Consumer Value – A Framework for Analysis and
Research. New York, NY: Routledge.
Hruby, P. (2006). Model-Driven Design Using Business Patterns. Berlin:
Springer Verlag.
Hull E., Jackson K. & Dick J. (2004). Requirements Engineering, Second
Edition. Berlin: Springer.
Ilayperuma, T, Zdravkovic, J. (2009). Value-Based Risk Management for
Web Information Goods, In Sushil K. Prasad, Susmi Routray, Reema
Khurana and Sartaj Sahni (Ed.), Third International Conference on Information Systems, Technology and Management (ICISTM-09), (Communications in Computer Science, pp. 64-75), Berlin: Springer.
ISO/IEC. (2002). Operational Aspects of Open-edi for Implementation. ISO
Standard 15944-1.
ISO/IEC. (2007). Business Transaction Scenarios - Accounting and Economic Ontology. ISO Standard 15944-4.
165
Jayaweera, P. & Petit, M. (2009). Classifying Business Rules to Guide the
Systematic Alignment of a Business Value Model to Business Motivation. In Hans Weigand, Hannes Werthner, Graham Gal (Ed,), Fourth International Workshop on Business/IT Alignment and Interoperability
(co-located with CAISE 2009), (CEUR Vol. 456), Netherlands: CEUR
Workshop Proceedings.
Johnston, S. (2005). UML 2.0 Profile for Software Services. IBM Cooperation.
Retrieved
March
15,
2009
from
http://www.ibm.com/developerworks/rational/library/05/419_soa/
Kaplan, R.S. & Nortan, D.P. (1996). Translating Strategy into Action: The
Balanced Scorecard. Boston, MA: Harvard Business School Press.
Kartseva, V., Gordijn, J., & Tan, Y. (2007). Value-based Design of Networked Enterprises Using e3 Control Patterns. In Pankaj Jalote and
Alistair Sutcliffe (Ed.). 15th IEEE International Requirements Engineering Conference, (pp.91-100), Los Alamitos, CA: IEEE Xplore,.
Kavakli, V. & Loucopoulos, P. (1999). Focus Issue on Legacy Information
Systems and Business Process Change: Modelling of Organisational
Change in the EKD Framework. Communications of the Association for
Information Systems, 2(6). Retrieved May 10, 2009 from
http://aisel.aisnet.org/cais/vol2/iss1/6
Kavakli, E. & Loucopoulos P. (2004). Goal Modeling Requirements Engineering: Analysis and Critique of Current Methods. In J. Krogstie, T.
Halpin & K. Siau (Ed.) Information Modeling Methods and Methodologies, (pp. 102-124), Hershey, PA, USA: IDEA Group.
Kavakli V. (2002). Goal Oriented Requirements Engineering: A Unifying
Framework. Requirements Engineering Journal, 6(4), 237-251.
Kherraf, S., Lefebvre, E. & Suryn, W. (2008). Transformation from CIM
to PIM Using Patterns and Archetypes. 19th Australian Software Engineering Conference (pp. 338-346), Perth, WA: IEEE Xplore.
Kleppe, A., Warmer, J. & Bast, W. (2003). MDA Explained. Boston, MA,
USA: Addison-Wesley Professional.
Levi, K. & Arsanjani, A. (2002). A Goal-Driven Approach to Enterprise
Component Identification and Specification. Communications of the
ACM, 45(10), 45-52.
Lewin, K. (1946). Action Research and Minority Problems, Journal of Special Issues, 2(4), 34-46.
Linder, J.C. & Cantrell, S. (2000). Changing Business Models: Surveying
the Landscape. Accenture - Institute for Strategic Change, Working Paper.
Retrieved
February
20,
2009
from
http://www.accenture.com/NR/rdonlyres/0DE8F2BE-5522-414C8E1B-E19CF86D6CBC/0/Surveying_the_Landscape_WP.pdf
166
López-Sanz, M., Acuña, C. J., Cuesta, C.E., Marcos, E. (2008). UML Profile
for the Platform Independent Modelling of Service-Oriented Architectures, In Flavio Oquendo (Ed.), First European Conference on Software
Architecture, (LNCS Vol. 4758, pp. 304-307). Berlin: Springer-Verlag.
Loucopoulos, P. & Kavakli, E. (1995). Enterprise Modelling and the Teleological Approach to Requirements Engineering. International Journal
of Intelligent and Cooperative Information Systems, 4(1), 45-79.
March, S. T. & Smith, G. (1995). Design and Natural Science Research on
Information Technology. Decision Support Systems, 15(4), 251-266
Markides, C. (1999). All the Right Moves: A Guide to Crafting Breakthrough
Strategy. USA: Harvard Business School Press.
McCarthy, W. E. (1982). REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review, 57(3), 554-578.
McEwen, S. (2004). Requirements: An Introduction, IBM Cooperation, Retrieved
April
5,
2009
from
http://www.ibm.com/developerworks/rational/library/4166.html?S_TA
CT=105AGX78&S_CMP=H
Morgan, G. (1983). Research Strategies: Modes of Engagement. In G. Morgan (Ed.) Beyond Method, (pp. 19-42). Beverly Hills, CA: Sage Publications.
Myers, M. D. (2008). Qualitative Research in Business and Management.
Sage Publications Ltd.
Mylopoulos, J., Castro, J. (2000). Tropos: A Framework for RequirementsDriven Software Development. In Brinkkemper, J., Lindencrona, E.,
and Solvberg, A. (Ed.), Information Systems Engineering: State of the
Art and Research Themes, (pp. 261-273). Springer.
Nuseibeh, B. & Easterbook, S. (2000). Requirements Engineering: A Roadmap. Conference on the Future of Software Engineering, (pp. 35-46),
New York, NY: ACM.
OASIS. (2006). Reference Model for Service Oriented Architecture 1.0.
Retrieved
June
12,
2009
from
http://www.oasisopen.org/committees/download.php/19679/soa-rm-cs.pdf
OASIS (2007). Web Services Business Process Execution Language Version
2.0. WS-BPEL, (2007). Retrieved May 4, 2009 from http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
Osterwalder, A. (2004). The Business Model Ontology - A Proposition in a
Design Science Approach. [PhD. Thesis] University of Lausanne.
Papazoglou, M. P. & van den Heuvel, W. (2006). Service-Oriented Design
and Development Methodology. International Journal of Web Engineering and Technology, 2(4), 412-442.
Parasuraman, A., Zeithaml, V. & Berry, L. (1988). SERVQUAL: A Multiple-item Scale for Measuring Consumer Perception of Service Quality.
Journal of Retailing, 64(1), 12-40.
167
Piccinelli, G. & Stammers, E. (2001). From E-Processes to E-Networks: an
E-Service-oriented approach. In Hamid R. Arabnia, Youngsong Mun
(Ed.) International Conference on Internet Computing, 3, (pp. 549553). CSREA Press.
Pijpers, V., Gordijn, J. & Akkermans, H. (2008). Aligning Information System Design and Business Strategy - A Starting Internet Company. In
Janis Stirna and Anne Persson (Ed.), First IFIP WG 8.1 Working Conference: Practice of Enterprise Modeling 2008, (LNBIP Vol. 15, pp.
47-61), Springer.
Pohl, K. (1996). Process-centered Requirements Engineering. New York,
USA: John Wiley & Sons, Inc.
Porter, M. (1998). Competitive Advantage: Creating and Sustaining Superior Performance. New York, USA: The Free Press.
Preist. C. (2004). A Conceptual Architecture for Semantic Web Services. In
F. van Harmelen, S.A. McIlraith & D. Plexousakis (Ed.), Third International Semantic Web Conference – ISWC 2004, (LNCS Vol. 3298, pp.
395-409). Berlin: Springer-Verlag.
Rappa, M. (2001). Managing the Digital Enterprise - Business Models on
the
Web.
Retrieved
January
10,
2009
from
http://digitalenterprise.org/models/models.html
Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M.,
Polleres, A., Feier, C., Bussler, C., & Fensel D. (2005). Web Service
Modeling Ontology. Applied Ontology, 1, 77-106.
Rosen, M. (2003). MDA, SOA and Technology Convergence. MDA Journal,
Retrieved
March
15,
2009
from
http://www.bptrends.com/publicationfiles/1203%20COL%20Frankel%20-%20MDA%20SOA%20-%20Rosen.pdf
Strauss, A. & Corbin, J. (1998). Basics of Qualitative Research: Technique
and Procedures for Developing Grounded Theory, 2, Thousand Oaks:
Sage Publications.
Takeda, H., Veerkamp, P., Tomiyama, T. & Yoshikawam, H. (1990). Modeling Design Processes. AI Magazine, 11(4), 37-48.
Timmers, P. (1998). Business Models for Electronic Markets. Electronic
Markets - The International Journal on Networked Business, 8, 3-8.
UML. (2009). Unified Modeling Language: Superstructure - Version 2.0.
Retrieved
April
4,
2009
from
http://www.omg.org/spec/UML/2.0/Superstructure/PDF/
UN/CEFACT. (2003). UN/CEFACT Modeling Methodology (UMM) User
Guide.
Retrieved
April
10,
2009
from
http://www.unece.org/cefact/umm/UMM_userguide_220606.pdf
UN. (2002). United Nations, Department of Economic and Social Affairs,
Common Data Base (CDB) Data Dictionary. Retrieved April 22, 2009
from http://unstats.un.org/unsd/cdbmeta/gesform.asp?getitem=398
168
van der Raadt, B., Gordijn, J. & Yu, E. (2005). Exploring Web Services
Ideas from a Business Value Perspective. International Conference on
Requirements Engineering - 2005, (pp. 53-62), IEEE Xplore.
van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A
Guided Tour. In. Fifth IEEE International Symposium on Requirements
Engineering - 2001, (pp. 0249-263), Toronto: IEEE Computer Society.
Vidales, S., García, A. & Aguilar, L. (2008). A new MDA Approach Based
on BPM and SOA to Improve Software Development Process. Polytechnical Studies Review, Tékhne, 6(9), 70-90.
Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A.
and Ilayperuma, T. (2006). Value Object Analysis and the Transformation from Value Model to Process Model, In Guy Doumeingts,
JörgMüller, Gérard Morel and Bruno Vallespir (Ed.), 2nd International
Conference on Interoperability of Enterprise Software and Applications
(INTEROP-ESA 2006), (Enterprise Interoperability: New Challenges
and Approaches, pp. 55-65), London: Springer-Verlag.
Weigand H., Johannesson P., Andersson B., Bergholtz M., Edirisuriya A.
and Ilayperuma T. (2007). Strategic Analysis Using Value Modeling:
The c3-value Approach, In Proceedings of the 40th Hawaii International
Conference on Systems Science (HICSS-40). (CD-ROM/Abstracts Proceedings, 175), Waikoloa, USA: IEEE Computer Society.
Weill, P. & Vitale, M. R. (2001). Place to Space: Migrating to eBusiness
Models. Boston: Harvard Business School Press.
White, S. (2006). Introduction to BPMN. OMG/Business Management Initiative. Retrieved May 4, 2009 from: http://www.bpmn.org/Documents/
Introduction%20to%20BPMN.pdf
W3C. (2004). Web Services Architecture, W3C Working Group Note 11
February 2004. Retrieved
December 15, 2008 from
http://www.w3.org/TR/ws-arch/wsa.pdf
Yu, S. E. (1995). Models for Supporting the Redesign of Organizational
Work. In Nora Comstock & Clarence Ellis (Ed.), Conference on Organizational Computing Systems (COOCS 1995). (pp. 226-236), New
York, NY, USA: ACM.
Yu, S. E. (1997). Towards Modelling and Reasoning Support for EarlyPhase Requirements Engineering. Third IEEE International Symposium
on Requirements Engineering (RE'97), (pp. 226-235)Washington, DC.,
USA: IEEE Computer Society.
Zlatev, Z., van Eck, P., Wieringa, R. & Gordijn, J. (2004). Goal-Oriented RE
for E-Services. In Proceedings of the International Workshop in Service-oriented Requirements Engineering - SoRE'04, Retrieved December
10,
2008
from
http://e3value.few.vu.nl/docs/bibtex/pdf/ZlatevGoal04.pdf
169
170
Appendix A
Transaction: InformationProvisioning
Application of Guideline 3,a: Identification of resources across planning,
identification, negotiation, actualization and post-actualization
Table A1. Resources across different phases of the transaction InformationProvisioning
Planning
PrimaryCareRegistration
Commitment for the treatment The Health services office offers
has been already established in Registration service information.
the PrimaryCareRegistration Resource: RegistrationServiceInfo
transaction and hence no resources identified in here.
Identification
InformationProvisioning
Primary care provides Accredi- Primary care provides information
tation information to the
regarding its services and resources
Health services office.
to register them to the Primary care
center.
Resource: Accreditation
Resource: PrimaryCareInformation
Negotiation
Rights for the resource transfers are already established in
the PrimaryCareRegistration
transaction. Therefore no resources are identified in this
phase.
Health services office gets
Right2RegisterPatients.
Primary care gets
Right2AccessPatientData from the
Health services office.
Primary care gets
Right2AccessKnowledgeServices
from the Health services office.
Primary care gets
Right2AccessSpecialistClinicInformat
ion from the Health services office.
Resource: Right2TreatmentServices
Right2AccessPatientPersonalData,
Right2AccessSpecialistClinicInformat
ion.
171
Post-actualization
Actualization
No resource flows are identified in
Health services office offers
this phase
PatientData to the Primary
care provider.
Registration office offers SpecialistClinicInformation to the
Primary care provider.
Registration office offers
KnowledgeOnSymptomsAndDiseases to the Primary care
provider.
Resource: PatientData, SpecialistClinicInformation,
KnowledgeOnSymptomsAndDiseases
No resources could be identified in the post-actualization
phase of this transaction.
No resources could be identified in
the post-actualization phase of this
transaction.
Application of Guideline 3,b: Identification of resources across different
phases considering internal values.
Next we re-examine each of the elicited resources, to identify internal
values, along all the five phases.
• In the planning phase of the transaction RegistrationInformationProvisioning, as in the case of the the PatientRegistration transaction, the
Primary care provider may find it is convenient if the Registration Office offers registration information services in different formats such as
e-catalogues and printed catalogues. Hence, we derive a new resources:
eCatalogue and PrintedCatalogue as two alternatives that replaces previously identified resource: RegistrationServiceInfo.
• In the Identification phase, of this transaction, we assume that the information verification had been already done by the Registration office.
• Also in the negotiation phase of this transaction, we do not derive any
new resources after considering the internal values.
• Considering the speed and reliability of the custody transfers in the actualization phase, we derive OnlineAccess2PatientRegistrationInfo.
• In the post-actualization phase of this transaction, we do not derive any
new resources, after considering internal values.
172
The figure below depicts the resource transfers between the Primary care
physician and services office.
Figure A1. e3 value business model depicting resource transfers between the primary care physician and the healthcare specialist.
Transaction: InitialTreatment
The transaction InitialTreatment and FullTreatment are alternative business
transactions offering two choices of resource treatment to a patient. That is,
for a particular patient, the Primary care physician offers either FullTreatment or IntitialTreatment in any given situation. The difference between
these two transactions is that in the former transaction, the primary care physician, Patient and Healthcare specialist collaborate with each other while in
the latter only the Primary care physician and the Patient involved in the
collaboration. As such, by applying Guideline 3 (3, a and 3, b), the identified
resources in this transaction show similarities to the resources identified in
the transaction FullTreatment.
Application of Guideline 3,a: Identification of resources across planning,
identification, negotiation, actualization and post-acualization
173
Table A2. Resources across different phases of the transaction InitialTreatment
Post-actualization Actualization
Negotiation Identification
Planning
InitialTreatment
Commitment for the treatment has been already established in the
PatientRegistration transaction and hence no resources identified in
here.
Patient provides Accreditation information to primary care.
Resources: Accreditation
Primary care offers Right to time slot to the patients.
patients offer Right to payment to primary care.
Resources: Right2TimeSlot, Right2Payment
Primary care offers InitialTreatment to the patients.
Primary care offers Right2GetAdvanceTreatment to the patients.
Primary care offers Right2GiveAdvanceTreatment to the Specialist.
Resources: InitialTreatment, Right2GetAdvanceTreatment,
Right2GetAdvanceTreatment.
Primary care offers Timeslot to post health examination.
Primary care offers Post-health examination to the patients.
Resources: TimeSlot2PostHealth Examination, PostHealthExamination.
Application of Guideline 3,b: Identification of resources across different
phases considering internal values.
Considering the similarity between the FullTreatment and InitialTreatment transaction, below, we summarize the resources identified by applying
Guideline 3, b.
• Planning: this phase leads to identifying the eCatalogue and PrintedCatalogue as different choices that replace the previously identified resource: RegistrationServiceInfo.
• Identification: two new transactions; PatientInformationProvisioning
for providing registration information of patients to primary care physicians and another; PrimaryCareRegistration for establishing commitments for the above transaction are identified.
174
•
Negotiation: a new resource; Right2CancelAppoinment is identified.
Additionally, considering the internal value customizability for obtaining a referral to a specialist healthcare clinic of patients’ preference, we
derive the resource SpecialistClinicInformation, for customers to get
first hand information about specialist clinics that they can be referred
to.
• Actualization: considering a new resource InitialTreatmentAtHome4Elders is identified as an alternative for the resource InitialTreatment.
• Post-actualization: considering responsiveness in the sense that the specialist healthcare clinic should respond to the primary care in order for
the latter to effectively carry out the post-health examination of the patient, we derive the resource; Access2PatientTreatmentInformation.
In Figure A2 below, we model the resource transfers identified considering the different phases as well as internal values. There are three actors
involved in this transaction: the Primary care physician, the Healthcare specialist and the Patient. The Primary care physician is responsible for providing initial treatment (InitialTreatment) to the patient followed by a referral
(Right2GetAdvanceTreatment) to get treatment from the Healthcare specialist. At the same time, the Primary care physician provides information regarding the referred patient giving the right for the Healthcare specialist to
treat the Patient.
Figure A2. e3 value model depicting InitialTreatment transaction
175
Transactions: AdvanceTreatment, SpecialistRegistration
Application of Guideline 3,a: Identification of resources across planning,
identification, negotiation, actualization and post-actualization phases.
Postactualization
Actualization
Negotiation
Identification Planning
Table A3. Resources across different phases of the transactions AdvanceTreatment
and SpecialistRegistration
AdvanceTreatment
SpecialistRegistration
Commitment for the treatment
has been already established in
the PatientRegistration transaction and hence no resources are
identified in here.
Patients provide Right to get
Advance treatment to the Healthcare specialist
Resources:
Right2GetAdvanceTreatment
Health care specialist offers
Right to time slot to the Patient.
Patient provides Right to payment to the Healthcare specialist.
Resources: Right2TimeSlot,
Right2Payment.
Patients get Advance treatment
from the Healthcare specialist.
Healthcare specialist gets Fee
from the Patient.
Resources: AdvanceTreatment,
Fee
No resources could be identified
in the post-actualization phase of
this transaction.
The Registration Office offers
Services catalogue
Resources: ServicesCatalogue
Specialist Clinics provide Specialist clinic information to register them to primary care center
Resources: SpecialistClinicInformation
Specialist Clinics get Right to get
patients referred.
Resources:
Right2GetPatientsReferred
Since this transaction focuses on
establishment of commitments
(e.g. right to get patients referred), we do not identify transfer of custody of objects in the
actualization phase.
Health services office offers periodic information bulletins to
Healthcare specialists.
Resources: PeriodicInformationBulletin.
Application of Guideline 3,b: Identification of resources across different
phases considering internal values.
Next we re-examine each of the elicited resources, to identify internal
values, along all the five phases.
• In the planning phase of both transactions in Table A3, the Specialist
Clinics may find it is convenient if the Health services office offers ser176
•
•
•
•
vices catalogues in different formats such as e-catalogues and printed
catalogues. Hence, we derive a new resource: eCatalogue and PrintedCatalogue as two alternatives that replace the previously identified resource: ServiceCatalogue.
In the Identification phase, of the transaction AdvanceTreatment, the
referral information provided by the patient will be checked against the
information Healthcare specialist received from the Primary care physician. As such we do not identify any new resources for the transaction
AdvanceTreatment. Assuming that the information from the Healthcare
specialist will be checked internally by the Health services office, we do
not derive new resources considering the internal values in this phase
for the SpecialistRegistration transaction.
In the negotiation phase of the transaction AdvanceTreatment, considering the internal values we derive the resource Right2CancelAppoinment
so that a Patient may have chance to cancel an existing appointment
within a reasonable time period.
Since there are no custody transfers involved in the registration of the
Healthcare specialist by the Health services office, we do not derive
any new resources for the transaction SpecialistRegistration. Also, in
the AdvanceTreatment transaction, we do not derive any new resources
considering the internal values in this phase.
In the post-actualization of the transaction SpecialistRegistration, the
Primary care physician may find it useful if they receive information
updates regarding health services from the Health services office. Thereby, we identify PeriodicInformationBulletin as a resource that could
be received by the Primary care physician from the Health services office. For the transaction AdvanceTreatment, we do not derive any new
resources in the post-actualization phase.
The above identified resource transfers are modeled in Figure A3 below
which models three actors: Health services office, Healthcare specialist and
Patient. The figure below models two transactions, the AdvanceTreatment
transaction between the Healthcare specialist and the Patient ( ) and the
transaction SpecialistRegistration between the Healthcare specialist and the
Health services office( ).
177
Figure A3. e3 value business model depicting AdvanceTreatment and SpecialistRegistration transactions.
178
Appendix B
Exploring the Use of Business Models for Designing E-Services Using
the MMOG Case
Application of Step 1: Generating a CIM/Business Model for the MMOG
case
Considering the MMOG case presented in Section 2.7.1, we identify the
following business transactions. We utilize the guidelines presented in Section 7.2.1 to identify the transactions below. However, here we do not develop a complete business model for the MMOG case as the primary goal of
this appendix is to explore the services designing method presented in Chapter 7. We use the REA business modeling method in this section to design
the business model.
• For providing access to the games by the Game Provider to the Game
Player, we introduce a transaction, GamesProvisioning. For the provisioning of the hosting service by the ISP to the Game Provider, we introduce one transaction HostingProvisioning. Furthermore, we introduce one transaction InternetAccessProvisioning for providing Internet
access by the ISP to the Game Player.
• For player profile creation at the Game Provider, we introduce one
transaction PlayerProfileCreation. Concerning the registration of ISPs
by the Game Provider, we introduce the ISPRegistration transaction.
Next, the transactions identified above are expanded along the planning,
identification, negotiation, actualization and post-actualization phases. In
here, we consider only the GamesProvisioning transaction. In Table A1 below, we summarize the economic events identified in this transaction along
these phases.
179
Post-actualization
Actualization
Negotiation
Identification
Planning
Table B1. Economic events, actors and resources of the transaction GamesProvisioning
Economic Events (EE), Actors (A) and Resources (R)
Game Provider (A) offers Catalogue (R) to the Game Player (A).
In return the Game Provider (A) obtains the Attention (R) of the
Game Player (A).
Economic Events (EE) – Publish Games Catalogue (Game Provider),
Obtain Attention (Game Player)
Game Player (A) provides Accreditation (R) to the Game Provider
(A).
Game Provider (A) compensates with Games Info. (R) to the Game
Player (A).
Economic Events (EE) – Obtain Game Selection (Game Player),
Offer Games Info. (Game Provider)
Game Provider (A) offers Right to Play Games (R) to the Game
Player (A).
Game Player (A) offers Right to Payment (R) to the Game Provider
(A).
Economic Events (EE) – Offer Right to Play Games (Game
Provider).
Obtain Right to Payment (Game Player)
Game Player (A) gets the Access to Games (R)
Game Provider (A) gets the custody of Money (R)
Economic Events (EE) – Deliver Games (Game Provider),
Obtain Payment (Game Player).
Game Player (A) gets FAQ Info (R).
Game Provider (A) gets Status (R).
Game Player (A) provides Error Reports (R) to the Game Provider
(A)
Game Provider (A) offers Solutions (R) to specific problems of the
Game Player (A).
Economic Events (EE) – Offer FAQ, Offer Solutions (Game
Provider),
Obtain Error Report, Obtain Player Satisfaction (Game Player)
In the above figure, we present the business model fragment for the GamesProvisioning transaction explored along five phases in the table above. In
Figure B1 below, the events are created from the MMOG perspective (i.e
provider perspective).
180
Figure B1. REA business model fragment for the Games Provisioning transaction of
the MMOG case. Symbols <A>, <EE>, <R> denote actor, economic event, and
resource, respectively
Application of Step 2: Generating CIM/Process Models for the MMOG
case.
In Figure B2, we consider the Offer Right to Play Games and Obtain Right
to Payment events forming a business service that we name Establish Contract. Following Step 1, a process shall be created from the perspective of
the MMOG provider.
Considering the organizational perspective, the business modeler will create
two UML partitions: Game Player and Game Provider. The modeler will
then explore the two major tasks (functional perspective) in this service:
a. offering right to play games, which will be realized by obtaining
a selection of games from the player; and
b. obtaining a right to payment by providing the player a contract.
By creating a composition of the outlined activities (behavioral aspect), refining them to the level of atomic business activities and including the internal rules, the modeler will create a process model as depicted in Figure B2.
Considering the informational aspect, the modeler will identify the messages/documents that have to be exchanged by the activities identified in the
behavioral aspect, and model those using UML objects (see Figure B2). The
181
obtained service process will begin when the Game Provider receives a player selection from the Game Player. The Game Provider then checks the information to examine if the player has a subscription with a payment due or
not. Based on this information, the provider will either offer a contract to the
Game Player, or decide on an acceptance of the player.
Figure B2. UML activity diagram exploring the details of the Establish Contract
service
Application of CIM to PIM Transformation Rules
The table below summarizes elements that are directly mapped from the
CIM-activity diagram to the PIM Service Profile model, after application of
transformation rules in Section 7.2.2.
182
Table B2. Summary of CIM-level elements and corresponding PIM/Service Profile
elements
Rule
1, a
1, b
Element types
Elements
CIMactivity
diagram
PIM Service Profile
CIM- activity
diagram
PIM Service Profile
Partition
Partition
Game Player
gamePlayerManagement
subscriptionManagement
receivePlayerSelection
Game Provider
2,a
2,b
Activity
Operation
Provide game
selection
Get payment
details
Provide acceptance/rejection
notification
Get contract/notification
Get player selection
Offer
games
cost and terms
Provide
contract/termination
notification
3,a
•
Resource
Message
Player selection
Cost/Terms
Player decision
Contract/Terminatio
n notice
sendContractTerms
receivePlayerDecision
sendContract
sendPaymentDueNotice
sendPlayerInformation
receiveGamesCost
receiveContractInformation
receivePaymentDueAmount
playerSelection
Cost/Terms
playerDecision
contract
paymentDueInformation
Considering Rule 1,(a), the gamePlayerManagement partition (see
Table B2) is responsible for the interactions of the Game Provider to the
Game Player. For this partition, a Service Provider, Service Consumer,
Service, Service Specification and Service Gateway elements are
created and named gamePlayerManager, subscriptionAssessor
gameContract,
gameContractInterface
and
183
•
•
•
•
gamePlayerManagementGateway. The Gateway element is added to
define that the service specification is accessible outside its hosting
partition.
Considering Rule 1,(b) subscriptionManagement partition (see Table
B2) is added to host the information retrieval activities of the Game
Provider, such as to Check if the player has a subscription in the CIMlevel activity diagram in Figure B2. Additionally a Service Provider,
Service Consumer, Service, Service Specification and Gateway
elements are added, for the created partition (see Figure B3). These
elements are named subscriptionAssessor, gamePlayerManager,
subscription,
subscriptionInterface
and
subscriptionManagementGateway.
The table above shows the elements that are directly identified
considering Rule 2, (a).
(Rule 2, b): the Operation elements receivePlayerStatus,
sendGamesInformation within subscriptionInterface are added (Figure
B3).
(Rule 2, c): the activity element Get contract/notification in the CIM is
decomposed
to
Operation
elements
“sendContract”
and
“sendPaymentDueNotice” within the gameContractInterface (Figure
B3). Additionally, Provide contract/termination notification in the CIM
Game Provider partition is decomposed to receiveContractInformation
and receivePaymentDueAmount Operation element within the
subscriptionInterface.
The “Check if the player has a subscription” and “check if the player has
a payment due” in the CIM-level are the assignment-type of activities, and
as such, are mapped to “selectPlayerInformation” and “selectPaymentDueInformation” in the PIM/Service Behavior (Figure B4). Considering
selecting games information, preparing contract terms, selecting player
decision information and preparing the final contract, and the preparing
payment due notice, assignment-type activities selectGamesInformation, ,
prepareContractTerms, prepareContract, preparePaymentDueInformation
are added to the PIM Service Behavior. Additionally, considering the fact
that the player information and contract information is already available with
the process itself, we decompose the activity, Get player notification and
perform its function within the assignment-type activity prepareContract.
•
•
184
(Rule 3, a) The information resource such as “Player selection” from
the CIM (see Figure B2) are mapped to the Message elements in the
PIM Service Profile (see Table B2 and Figure B3).
(Rule 3, b) Considering the decomposition of the activity Get contract/termination notification in the functional aspects in Rules 2(c), the
information resource “Contract/termination notice” from the CIM-
level activity diagram is decomposed to the Message elements “contract” and “paymentDueNotice” in PIM/Service Profile. Additionally,
considering the decomposition of the CIM-level activity Provide contract/termination notification new Message elements decisionInformation and contractInformation is added to the PIM Service Profile (see
Figure B3).
185
186
Figure B3. PIM/Service Profile for gameContract and subscription Services
Figure B4 below depicts the behavioral part of the PIM service model obtained when applying the transformation rules on the CIM service Establish
Contract.
Figure B4. PIM service behavior model gameContract and subscription Services
187
188
DEPARTMENT OF COMPUTER AND SYSTEMS SCIENCES
Stockholm University/KTH
www.dsv.su.se
Ph.D. theses:
No 91-004 Olsson, Jan
An Architecture for Diagnostic Reasoning Based on Causal Models
No 93-008 Orci, Terttu
Temporal Reasoning and Data Bases
No 93-009 Eriksson, Lars-Henrik
Finitary Partial Definitions and General Logic
No 93-010 Johannesson, Paul
Schema Integration Schema Translation, and Interoperability in Federated Information Systems
No 93-018 Wangler, Benkt
Contributions to Functional Requirements Modelling
No 93-019 Boman, Magnus
A Logical Specification for Federated Information Systems
No 93-024 Rayner, Manny
Abductive Equivalential Translation and its Application to Natural-Language Database Interfacing
No 93-025 Idestam-Almquist, Peter
Generalization of Clauses
No 93-026 Aronsson, Martin
GCLA: The Design, Use, and Implementation of a Program Development
No 93-029 Boström, Henrik
Explanation-Based Transformation of Logic programs
No 94-001 Samuelsson, Christer
Fast Natural Language Parsing Using Explanation-Based Learning
No 94-003 Ekenberg, Love
Decision Support in Numerically Imprecise Domains
No 94-004 Kowalski, Stewart
IT Insecurity: A Multi-disciplinary Inquiry
No 94-007 Asker, Lars
Partial Explanations as a Basis for Learning
No 94-009 Kjellin, Harald
A Method for Acquiring and Refining Knowledge in Weak Theory Domains
No 94-011 Britts, Stefan
Object Database Design
No 94-014 Kilander, Fredrik
Incremental Conceptual Clustering in an On-Line Application
No 95-019 Song, Wei
Schema Integration: - Principles, Methods and Applications
No 95-050 Johansson, Anna-Lena
Logic Program Synthesis Using Schema Instantiation in an Interactive Environment
No 95-054 Stensmo, Magnus
Adaptive Automated Diagnosis
No 96-004 Wærn, Annika
Recognising Human Plans: Issues for Plan Recognition in Human - Computer Interaction
189
No 96-006 Orsvärn, Klas
Knowledge Modelling with Libraries of Task Decomposition Methods
No 96-008 Dalianis, Hercules
Concise Natural Language Generation from Formal Specifications
No 96-009 Holm, Peter
On the Design and Usage of Information Technology and the Structuring of Communication and Work
No 96-018 Höök, Kristina
A Glass Box Approach to Adaptive Hypermedia
No 96-021 Yngström, Louise
A Systemic-Holistic Approach to Academic Programmes in IT Security
No 97-005 Wohed, Rolf
A Language for Enterprise and Information System Modelling
No 97-008 Gambäck, Björn
Processing Swedish Sentences: A Unification-Based Grammar and Some Applications
No 97-010 Kapidzic Cicovic, Nada
Extended Certificate Management System: Design and Protocols
No 97-011 Danielson, Mats
Computational Decision Analysis
No 97-012 Wijkman, Pierre
Contributions to Evolutionary Computation
No 97-017 Zhang, Ying
Multi-Temporal Database Management with a Visual Query Interface
No 98-001 Essler, Ulf
Analyzing Groupware Adoption: A Framework and Three Case Studies in Lotus
Notes Deployment
No 98-008 Koistinen, Jari
Contributions in Distributed Object Systems Engineering
No 99-009 Hakkarainen, Sari
Dynamic Aspects and Semantic Enrichment in Schema Comparison
No 99-015 Magnusson, Christer
Hedging Shareholder Value in an IT dependent Business society - the Framework
BRITS
No 00-004 Verhagen, Henricus
Norm Autonomous Agents
No 00-006 Wohed, Petia
Schema Quality, Schema Enrichment, and Reuse in Information Systems Analysis
No 01-001 Hökenhammar, Peter
Integrerad Beställningsprocess vid Datasystemutveckling
No 01-008 von Schéele, Fabian
Controlling Time and Communication in Service Economy
No 01-015 Kajko-Mattsson, Mira
Corrective Maintenance Maturity Model: Problem Management
No 01-019 Stirna, Janis
The Influence of Intentional and Situational Factors on Enterprise Modelling Tool
Acquisition in Organisations
No 01-020 Persson, Anne
190
Enterprise Modelling in Practice: Situational Factors and their Influence on Adopting a Participative Approach
No 02-003 Sneiders, Eriks
Automated Question Answering: Template-Based Approach
No 02-005 Eineborg, Martin
Inductive Logic Programming for Part-of-Speech Tagging
No 02-006 Bider, Ilia
State-Oriented Business Process Modelling: Principles, Theory and Practice
No 02-007 Malmberg, Åke
Notations Supporting Knowledge Acquisition from Multiple Sources
No 02-012 Männikkö-Barbutiu, Sirkku
SENIOR CYBORGS- About Appropriation of Personal Computers Among Some
Swedish Elderly
People
No 02-028 Brash, Danny
Reuse in Information Systems Development: A Qualitative Inquiry
No 03-001 Svensson, Martin
Designing, Defining and Evaluating Social Navigation
No 03-002 Espinoza, Fredrik
Individual Service Provisioning
No 03-004 Eriksson-Granskog, Agneta
General Metarules for Interactive Modular Construction of Natural Deduction
Proofs
No 03-005 De Zoysa, T. Nandika Kasun
A Model of Security Architecture for Multi-Party Transactions
No 03-008 Tholander, Jakob
Constructing to Learn, Learning to Construct - Studies on Computational Tools for
Learning
No 03-009 Karlgren, Klas
Mastering the Use of Gobbledygook - Studies on the Development of Expertise
Through Exposure to Experienced Practitioners' Deliberation on Authentic Problems
No 03-014 Kjellman, Arne
Constructive Systems Science - The Only Remaining Alternative?
No 03-015 Rydberg Fåhræus, Eva
A Triple Helix of Learning Processes - How to cultivate learning, communication
and collaboration among distance-education learners
No 03-016 Zemke, Stefan
Data Mining for Prediction - Financial Series Case
No 04-002 Hulth, Anette
Combining Machine Learning and Natural Language Processing for Automatic
Keyword Extraction
No 04-011 Jayaweera, Prasad M.
A Unified Framework for e-Commerce Systems Development: Business Process
Patterns Perspective
No 04-013 Söderström, Eva
B2B Standards Implementation: Issues and Solutions
No 04-014 Backlund, Per
Development Process Knowledge Transfer through Method Adaptation, Implementation, and Use
191
No 05-003 Davies, Guy
Mapping and Integration of Schema Representations of Component Specifications
No 05-004 Jansson, Eva
Working Together when Being Apart – An Analysis of Distributed Collaborative
Work through ICT from an Organizational and Psychosocial Perspective
No 05-007 Cöster, Rickard
Algorithms and Representations for Personalised Information Access
No 05-009 Ciobanu Morogan, Matei
Security System for Ad-hoc Wireless Networks based on Generic Secure Objects
No 05-010 Björck, Fredrik
Discovering Information Security Management
No 05-012 Brouwers, Lisa
Microsimulation Models for Disaster Policy Making
No 05-014 Näckros, Kjell
Visualising Security through Computer Games
Investigating Game-Based Instruction in ICT Security: an Experimental approach
No 05-015 Bylund, Markus
A Design Rationale for Pervasive Computing
No 05-016 Strand, Mattias
External Data Incorporation into Data Warehouses
No 05-020 Casmir, Respickius
A Dynamic and Adaptive Information Security Awareness (DAISA) approach
No 05-021 Svensson, Harald
Developing Support for Agile and Plan-Driven Methods
No 05-022 Rudström, Åsa
Co-Construction of Hybrid Spaces
No 06-005 Lindgren, Tony
Methods of Solving Conflicts among Induced Rules
No 06-009 Wrigstad, Tobias
Owner-Based Alias Management
No 06-011 Skoglund, Mats
Curbing Dependencies in Software Evolution
No 06-012 Zdravkovic, Jelena
Process Integration for the Extended Enterprise
No 06-013 Olsson Neve, Theresia
Capturing and Analysing Emotions to Support Organisational Learning:
The Affect Based Learning Matrix
No 06-016 Chaula, Job Asheri
A Socio-Technical Analysis of Information Systems Security Assurance
A Case Study for Effective Assurance
No 06-017 Tarimo, Charles N.
ICT Security Readiness Checklist for Developing Countries:
A Social-Technical Approach
No 06-020 Kifle Gelan, Mengistu
A Theoretical Model for Telemedicine
- Social and Value Outcomes in Sub-Saharan Africa
No 07-001 Fernaeus, Ylva
Let’s Make a Digital Patchwork
Designing for Children’s Creative Play with Programming Materials
192
No 07-003 Bakari, Jabiri Kuwe
A Holistic Approach for Managing ICT Security in Non-Commercial Organisations
A Case Study in a Developing Country
No 07-004 Sundholm, Hillevi
Spaces within Spaces: The Construction of a Collaborative Reality
No 07-005 Hansson, Karin
A Framework for Evaluation of Flood Management Strategies
No 07-007 Aidemark, Jan
Strategic Planning of Knowledge Management Systems
- A Problem Exploration Approach
No 07-009 Jonsson, Martin
Sensing and Making Sense
Designing Middleware for Context Aware Computing
No 07-013 Kabilan, Vandana
Ontology for Information Systems (O4IS) Design Methodology:
Conceptualizing, Designing and Representing Domain Ontologies
No 07-014 Mattsson, Johan
Pointing, Placing, Touching
- Physical Manipulation and Coordination Techniques for Interactive Meeting
Spaces
No 07-015 Kessler, Anna-Maria
A Systemic Approach Framework for Operational Risk
- SAFOR
No 08-001 Laaksolahti, Jarmo
Plot, Spectacle and Experience: Contributions to the design and evaluation of Interactive Storytelling
No 08-002 Van Nguyen Hong
Mobile Agent Approach to Congestion Control in Heterogeneous Networks
No 08-003 Rose-Mharie Åhlfeldt
Information Security in Distributed Healthcare
- Exploring the Needs for Achieving Patient Safety and Patient Privacy
No 08-004 Sara Ljungblad
Beyond users:
Grounding technology in experience
No 08-005 Eva Sjöqvist
Electronic Mail and its Possible Negative Aspects in Organizational Contexts
No 08-006 Thomas Sandholm
Statistical Methods for Computational Markets
– Proportional Share Market Prediction and Admission Control
No 08-007 Lena Aggestam
IT-supported Knowledge Repositories:
Increasing their Usefulness by Supporting Knowledge Capture
No 08-008 Jaana Nyfjord
Towards Integrating Agile Development and Risk Management
No 08-009 Åsa Smedberg
Online Communities and Learning for Health
- The Use of Online Health Communities and Online Expertise for People with
Established Bad Habits
193
No 08-010 Martin Henkel
Service-based Processes
- Design for Business and Technology
No 08-012 Jan Odelstad
Many-Sorted Implicative Conceptual Systems
No 09-001 Marcus Nohlberg
Securing Information Assets
- Understanding, Measuring and Protecting against Social Engineering Attacks
No 09-002 Maria Håkansson
Playing with Context
- Explicit and Implicit Interaction in Mobile Media Applications
No 09-003 Petter Karlström
Call of the Wild
Using language technology in the second language classroom
No 09-009 Ananda Edirisurya
Design Support for e-Commerce Information Systems using Goal, Business and
Process Modelling
No 10-005 Moses Niwe
Organizational Patters for Knowledge Capture in B2B Engagements
No 10-007 Mats Wiklund
Perception of Computer Games in Non-Gaming Contexts
No 10-008 Petra Sundström
Designing Affective Loop Experiences
No 10-009 Tharaka Ilayperuma
Improving E-Business Design through Business Model Analysis
194
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement