general framework for service engineering analysis …dro.deakin.edu.au › eserv › du:30115369...
TRANSCRIPT
i
GENERAL FRAMEWORK FOR SERVICE
ENGINEERING ANALYSIS AND DESIGN
By
Purnomo Yustianto, (ST. MT.)
Submitted in fulfilment of the requirements for the degree of
Doctor of Philosophy
Deakin University
June, 2018
iv
Acknowledgement
On the surface, this thesis may appear as the reporting of an academic
journey. But on a personal level, it is a map of an accomplished quest. As,
any quest, the journey leads to several side-quests in collecting pertinent
artefacts along the way. It has been a journey of enjoyment, fulfilling
curiosities and ultimately leading to a self-discovery.
As a closure for this part of the journey, a humble gratitude is
offered to a number of people taking part in the journey:
Prof Robin Doss as the main supervisor of this research, with his
patience in allowing a curiosity to turn into this research work.
Dr Suhardi, as my local supervisor, with his guidance in initiating
the research and facilitation in completing this work.
All of Deakin University team: Prof Bas Baskaran, Prof John
Yearwood, Prof Yong Xiang, Associate Professor Jo Coldwell-
Neilson, Lina Darliana, Bec Anderson-Peters, Nghia Dang, and
others, with their warm hospitality and support in making Deakin
University my research almamater.
My research colleagues, Novianto Budi K, Deni Prayitno, Haris
Santika, Silvia, Agustinus Andriyanto, and all members of Service
Computing Research Group of Institut Teknologi Bandung, which
provide support, discussion and material for this research.
v
The entire supporting group on Doctoral Endorsement Program of
West Java Provincial Government: Dedi Mulyadi, Candrawulan,
Nunik Mulyana, and the West Java Communication and Informatics
Agency, which facilitate both my research and leave of absence while
conducting the research.
And ultimately to my beloved family: Mother, sisters, wife and kids,
for their blessing for me to endure this strange quest, and most
importantly, for their patience on the amount of my time given to it.
All other parties whose name is left unmentioned here, which
intentionally or not provided partial contributions to the overall
completion of this work.
The academic contributions of this research are mainly focused, but
hopefully a real dent is curved on the service science research landscape.
And this dent is dedicated to fellow researchers.
Purnomo Yustianto
Bandung, Indonesia
28 June 2018
vi
Publication List
1. Suhardi, Budhiputra, P.M. and Yustianto, P., 2014, November.
Service engineering framework: A simple approach.
In Information Technology Systems and Innovation (ICITSI),
2014 International Conference on (pp. 130-134). IEEE.
2. Yustianto, P., Doss, R. And Suhardi, 2015, November.
Consolidating service enginering perspectives. In Information
Technology Systems and Innovation (ICITSI), 2015 International
Conference on (pp. 1-7). IEEE.
3. Suhardi, Doss, R. and Yustianto, P., 2015. Service engineering
based on service oriented architecture methodology. Telkomnika,
13(4), p.1466.
4. Suhardi, Kurniawan, N.B., Prayitno, D., Sembiring, J. and
Yustianto, P., 2017, July. Public complaint service engineering
based on good governance principles. In Research and Innovation
in Information Systems (ICRIIS), 2017 International Conference
on (pp. 1-6). IEEE.
5. Silvia, Suhardi, and Yustianto, P., 2016, October. Business
process improvement of district government innovation service:
Case study Cimahi Tengah District of Cimahi. In Information
vii
Technology Systems and Innovation (ICITSI), 2016 International
Conference on (pp. 1-6). IEEE.
6. Santika, H., Suhardi, and Yustianto, P., 2017, May. Engineering
local government financial service system under good governance
principles: Case study: Cimahi government city. In Information
and Communication Technology (ICoIC7), 2017 5th International
Conference on (pp. 1-6). IEEE.
7. Yustianto, P. and Doss, R. and Suhardi, 2017, October. Activities
and artifacts in service engineering: Case study report of service
engineering framework. In Information Technology Systems and
Innovation (ICITSI), 2017 International Conference on (pp. 373-
377). IEEE.
8. Yustianto, P. and Doss, R. and Suhardi, 2018. A Unifying
Structure of Metamodel Landscape (Accepted on 18 September
2018 by Journal of Modelling in Management).
9. Yustianto, P. and Doss, R.,Suhardi and Kurniawan, N.B., 2018.
Consolidating Service Engineering Ontologies: Building Service
Ontology from SOA Modeling Language (SoaML) (submitted to
Information Technology Systems and Innovation International
Conference 2018).
10. Yustianto, P. and Doss, R., Suhardi and Kurniawan, N.B., 2018.
General Framework for Service Engineering Analysis and Design
viii
based on SoaML (Submitted to Journal of Systems Science and
Systems Engineering).
11. Yustianto, P. and Doss, R. 2018. Metamodel for Artefacts in
Service Engineering Analysis and Design (accepted and
presented on 13 September 2018 in 20th International
Conference on Service-Oriented Architecture and Engineering
Applications)
ix
Abstract
The term ‘service engineering’ is generally understood as a process
of devising a service system. But beyond that understanding, the term is
still regarded as an ‘open’ research challenge due to unspecified details
and conflicting perspectives. Within the multi-discipline nature of service
science, two streams contribute to the ‘service engineering’ concept: the
classic business-side and the emerging informatics side. This work
consolidates these two overlapping perspectives.
This research produced a service engineering framework labelled as
the General Service Engineering Framework (GSEF) which covers service
aspects from the business side through to the informatics side, i.e.
Business Capability, Business Model, Service Value, Interaction Model,
Process Model and, Software-Service Model.
As a part of the framework, ontological basis of service engineering
is defined. The ontology collects and specifies components pertinent
within the context of service engineering, along with the relationship
between the concepts. The software-service ontology was drawn from the
informatics domain, while the generalized ontology of a service system
was built from both a business management and the information system
perspective.
The framework itself is presented in a structure of three component
layers: Activity, Artefact, and Modelling. The activity characterizes the
phases and steps of analysis and design process. The artefact defines the
x
product of each step while also implying the dependency and flow of the
produced artefact. The modelling layer is an open container which
proposes a format to present the artefact, based on a specific modelling
language.
The proposed framework was empirically evaluated with a series of
case studies and theoretically validated with an ontology evaluation. In
its final version, the framework specifies four main activities with sixteen
types of artefacts to produce within the context of service analysis and
design.
As an additional contribution, the research also provides a
structured landscape of a metamodel from both industrial and academic
perspectives. The landscape is a product of exploring several potential
metamodels for representing an artefact. The exploration enriches the
suggested artefact format from the original eighteen formats to thirty
alternatives of a metamodel.
xi
Table of Content
Acknowledgement ..................................................................................... iv
Publication List ........................................................................................ vi
Abstract .................................................................................................... ix
Chapter 1 Introduction .............................................................................. 1
1.1 Motivation ............................................................................................ 1
1.2 Objective and Scope ............................................................................. 3
1.3 Research Problem ................................................................................ 6
1.4 Research Activities .............................................................................. 7
1.5 Contributions ..................................................................................... 11
1.6 Chapter Overview .............................................................................. 13
Chapter 2 Literature Review ................................................................... 16
2.1 Defining a ‘Service’ ............................................................................ 16
2.2 Classic Service Engineering .............................................................. 19
2.3 Service Oriented Architecture ........................................................... 25
2.3.1 Service Oriented Methodology ................................................. 28
2.3.2 Modelling in Service Oriented Analysis .................................. 32
2.4 Informatics Service Engineering ....................................................... 34
2.4.1 Service Engineering and Software Engineering ..................... 35
2.4.2 Service Engineering and SOA ................................................. 36
2.5 Research Opportunities in Service Engineering .............................. 41
Chapter 3 Service Engineering Ontology ................................................. 45
3.1 Ontology Defined ............................................................................... 45
3.2 Related Work ..................................................................................... 48
3.3 Software Service Ontology ................................................................ 52
3.3.1 Ontology of SoaML ................................................................... 53
3.3.2 ISO/IEC SOA Ontology ............................................................ 60
3.4 General Service Ontology .................................................................. 63
3.4.1 Ontology Source Material ........................................................ 63
xii
3.4.2 Consolidated Ontology ............................................................. 69
3.4.3 Differentiating Software from General Context ..................... 71
3.4.4 Consolidated Software Ontology ............................................. 73
3.5 Patterns of Service System ................................................................ 76
Chapter 4 Service Engineering Framework ............................................. 81
4.1 Introduction ....................................................................................... 81
4.2 Preliminary Framework .................................................................... 86
4.2.1 Identification Stage .................................................................. 88
4.2.2 Design Stage ............................................................................. 91
4.3 Case Studies ....................................................................................... 93
4.3.1 Case Study 1 – Citizen Registry .............................................. 93
4.3.2 Case Study 2 – Citizen Relationship Management ................ 97
4.3.3 Case Study 3 – Accounting Information Service .................... 99
4.3.4 Evaluation of Case Studies .................................................... 105
4.4 Service Engineering with SoaML .................................................... 110
4.4.1 Specification of SoaML Activity Flow .................................... 110
4.4.2 Case Study with SoaML ......................................................... 114
4.4.3 SoaML Case Study Evaluation .............................................. 119
Chapter 5 Modelling in Service Engineering .......................................... 123
5.1 Metamodel Exploration ................................................................... 123
5.1.1 Defining Model ....................................................................... 124
5.1.2 Model Taxonomy .................................................................... 126
5.1.3 Metamodel Anatomy .............................................................. 128
5.1.4 Building Metamodel Landscape ............................................ 130
5.1.5 Metamodel Landscape............................................................ 131
5.1.6 Metamodel Grouping .............................................................. 136
5.1.7 Metamodel Proliferation Pattern .......................................... 145
5.1.8 Discussion on Metamodel Landscape Structure ................... 147
5.2 Service Engineering Ontology and Artefact ................................... 148
5.2.1 Artefacts in Activity 1 (Understanding Service Context) ..... 149
5.2.2 Artefacts in Activity 2 (Defining Service Concept) ............... 151
5.2.3 Artefacts in Activity 3 (Business Service Design)................. 152
5.2.4 Artefacts in Activity 4 (Software Service Design) ................. 154
5.3 Alternative Service Engineering Metamodels ................................ 156
5.3.1 Business Motivation Model .................................................... 158
5.3.2 Value Definition Modelling Language................................... 159
5.3.3 Business Modelling ................................................................ 161
xiii
5.3.4 Interaction Modelling ............................................................. 165
Chapter 6 Conclusion ............................................................................. 172
6.1 Summary .......................................................................................... 172
6.3 Limitations and Directions for Future Work.................................. 175
Bibliography .......................................................................................... 177
xiv
List of Tables
Table 1.1: Dictionary Definition of ‘Framework’ .......................................... 3
Table 1.2: Selected Usage of ‘Framework’ Terminology .............................. 4
Table 2.1: An Incomplete List of Service Oriented Methodology .............. 29
Table 2.2: Stages of SOMA Methodology ................................................... 30
Table 2.3: Stages of MSOAM Methodology ................................................ 31
Table 2.4: Service Oriented Modelling Language ...................................... 33
Table 2.5: Service Engineering Framework with SOA .............................. 37
Table 3.1: SOA Characteristic Identifiers .................................................. 51
Table 3.2: SoaML Conceptual Components ............................................... 54
Table 3.3: ISO/IEC 18384:2016 SOA Conceptual Components ................. 61
Table 3.4: Identified Standard Documents for Concepts Definition ......... 64
Table 3.5: Entity-related Concept Definitions ........................................... 65
Table 3.6: Process-related Concept Definitions ......................................... 65
Table 3.7: Activity (sub-process)-related Concept Definitions .................. 66
Table 3.8: Task (atomic-activity-related Concept Definitions ................... 66
Table 3.9: Collaboration-related Concept Definitions ............................... 66
Table 3.10: Choreography-related Concept Definitions ............................. 66
Table 3.11: Interaction-point -related Concept Definitions ....................... 67
Table 3.12: Interface -related Concept Definitions .................................... 67
Table 3.13: Operation -related Concept Definitions .................................. 67
Table 3.14: Operation -related Concept Definitions .................................. 67
Table 3.15: Service-related Concept Definitions ........................................ 67
Table 3.16: Capability-related Concept Definitions ................................... 68
Table 3.17: Business Model-related Concept Definitions .......................... 68
Table 3.18: Rule-related Concept Definitions ............................................ 68
Table 3.19: Contract-related Concept Definitions ..................................... 68
Table 3.20: Value-related Concept Definitions .......................................... 68
Table 3.21: Role-related Concept Definitions ............................................. 68
xv
Table 3.22: Hierarchy of 17 Merged Concept Definitions.......................... 69
Table 3.23: Typology of the Service Encounter with examples ................. 71
Table 3.24: Concepts for Software Service Context ................................... 74
Table 4.1: Service Engineering Framework (prototype) ............................ 87
Table 4.2: Key Performance Indicator Analysis (Case Study 1) ............... 94
Table 4.3: Service Engineering Modelling Aspects (from Case Study) ... 109
Table 4.4: Sample of Business Goals (Smart Campus) ........................... 117
Table 4.5: Sample of Service Goals (Smart Campus) .............................. 117
Table 4.6: Comparison of SoaML and UML for Service Modelling ......... 120
Table 5.1: Metamodels Set (Coded and Sorted) ....................................... 134
Table 6.1: Research Results ...................................................................... 175
xvi
List of Figures
Figure 1.1: Design Science Research Cycles ................................................ 7
Figure 1.2: Research Flow............................................................................. 9
Figure 1.3: Research Content Mapping ...................................................... 14
Figure 2.1: Service Input-Output Model .................................................... 17
Figure 2.2: Areas of Service Engineering ................................................... 21
Figure 2.3: Stages of Service Engineering ................................................. 21
Figure 2.4: Synthesized NSD Framework .................................................. 23
Figure 2.5: SSDP Frameworks ................................................................... 25
Figure 2.6: Elements of Service Oriented Analysis and Design................ 26
Figure 2.7: Structure of Service Oriented Methodology ............................ 28
Figure 2.8: Comparison of SOMA and MSOAM concepts coverage .......... 32
Figure 2.9: Scientific Publication of ‘Service’ Modelling [65] .................... 34
Figure 2.10: Business-IT Alignment Model Framework ........................... 38
Figure 2.11: Derivation of Business Service .............................................. 39
Figure 2.12: Derivation of Software Service .............................................. 40
Figure 2.13: Context Positioning of Research Scope.................................. 43
Figure 3.1: Model, Metamodel and Ontologies .......................................... 46
Figure 3.2: Research Flow and Content Map (Chapter 3) ......................... 47
Figure 3.3: Metamodel of Service System .................................................. 48
Figure 3.4: Metamodel of Service Concept ................................................. 49
Figure 3.5: Service Package of SOA Metamodel ........................................ 50
Figure 3.6: Succession of SOA Open Standard .......................................... 53
Figure 3.7: Interface-based Service version of SoaML Ontology .............. 56
Figure 3.8: Contract-based Service version of SoaML Ontology ............... 57
Figure 3.9: Service Interface-based Service version of SoaML Ontology . 58
Figure 3.10: SoaML Ontological Structure ................................................ 60
Figure 3.11: ISO/IEC 18384:2016 SOA Ontological Structure ................. 62
Figure 3.12: General Service Engineering Ontology ................................. 69
xvii
Figure 3.13: Typology of Customer Contact [4] ......................................... 72
Figure 3.14: Consolidated Software Service Ontology .............................. 74
Figure 3.15: Model of a Simple Service System ......................................... 77
Figure 3.16: Model of a B2B service pattern .............................................. 78
Figure 3.17: Model of a multi-provider service pattern ............................. 79
Figure 4.1: Research Flow and Content Map (Chapter 4) ......................... 81
Figure 4.2: Integrated Methodology for Service-Oriented System ........... 82
Figure 4.3: Service Engineering Framework (1st iteration) ..................... 88
Figure 4.4: BMC context in Service Engineering ...................................... 90
Figure 4.5: Service Blueprinting Template ................................................ 91
Figure 4.6: BPMN of the ‘to-be’ business process (Case Study 1) ............. 95
Figure 4.7: Integrated Service Architecture (Case Study 1) ..................... 96
Figure 4.8: Adapted Service Engineering Framework (Case Study 1) ..... 96
Figure 4.9: BMPN of the ‘to-be’ Business Process (Case Study 2) ............ 98
Figure 4.10: Component Dependency Diagram (Case Study 2) ................ 98
Figure 4.11: Adapted Service Engineering Framework (Case Study 2) ... 99
Figure 4.12: Component Business Model (Case Study 3) ........................ 100
Figure 4.13: E-R Diagram (Case Study 3) ................................................ 101
Figure 4.14: Responsibility Assignment Matrix (Case Study 3) ............. 102
Figure 4.15: Software Service Architecture (Case Study 3) .................... 103
Figure 4.16: Sequence Diagram in Case Study 3 .................................... 104
Figure 4.17: Use Case Diagram in Case Study 3 ..................................... 104
Figure 4.18: Adapted Service Engineering Framework (Case Study 3) . 104
Figure 4.19: Adapted Service Engineering Framework (Case Studies) . 108
Figure 4.20: Service Engineering Framework (2nd iteration) ................ 109
Figure 4.21: SoaML Top-Down Approaches Artefacts Flow ................... 111
Figure 4.22: Regrouping SoaML Artefacts into Activities ...................... 112
Figure 4.23: Incorporating SoaML Artefacts into Framework ............... 113
Figure 4.24: Service Engineering Framework (3rd iteration) ................. 113
Figure 4.25: Package Diagram of Project Domains (Smart Campus) ..... 114
xviii
Figure 4.26: Catalogue of Software-Services (Smart Campus) ............... 115
Figure 4.27: SoaML Capability Diagram (Smart Campus) ..................... 117
Figure 4.28: SoaML Service Interface Diagram (Smart Campus) .......... 118
Figure 4.29: SoaML’s Participant Diagram (Smart Campus) ................. 119
Figure 4.30: SoaML’s Service Architecture (Smart Campus) ................. 119
Figure 5.1: Research Flow and Content Map (Chapter 5) ....................... 123
Figure 5.2: Analysis-Synthesis Bridge Model .......................................... 125
Figure 5.3: Metamodel components .......................................................... 128
Figure 5.4: Metamodel Relationship (arranged in similarity) ................ 135
Figure 5.5: Metamodel Groupping ............................................................ 137
Figure 5.6: Service Engineering Framework Structure (3rd iteration) .. 149
Figure 5.7: Artefact Ontological Position in (Activity 1.1) ...................... 150
Figure 5.8: Artefact Ontological Position in (Activity 1.2) ...................... 151
Figure 5.9: Artefact Ontological Position in (Activity 2.1) ...................... 153
Figure 5.10: Artefact Ontological Position in (Activity 2.2) .................... 155
Figure 5.11: Sample of Business Motivation Model Artefact .................. 158
Figure 5.12: Sample of VDML Capability Library .................................. 160
Figure 5.13: Sample VDML Capability Management ............................. 161
Figure 5.14: Sample of Service Dominant Business Model (SDBM)....... 162
Figure 5.15: BM Cube components mapping with BMC ......................... 163
Figure 5.16: Structure of Service BMC (S-BMC) ..................................... 164
Figure 5.17: Sample of S-BMC Artefact with five party layers .............. 164
Figure 5.18: Sample of Process Chain Network (PCN) Artefact ............. 165
Figure 5.19: Network of Interactions in PCN .......................................... 166
Figure 5.20: Diagrams in ServiceML ....................................................... 167
Figure 5.21: Sample of Service Journey Modelling Language (SJML) ... 168
Figure 5.22: SJML abstraction for multi-participant interaction ........... 169
Figure 5.23: Metamodels Options for Service Engineering Framework . 170
Figure 6.1: Map of Research Artefacts ..................................................... 173
1
Chapter 1
Introduction
1.1 Motivation
The global business landscape trend in shifting its primary focus from
products as an output to the service provision process is academically
recognized as a shift from Goods-dominant logic (GDL) to Services-
dominant logic (SDL). While the classic GDL only recognizes ‘goods’ as a
basis of an exchange, SDL views ‘service’ as the fundamental basis of all
economic exchange [1].
SDL also identifies an abstract concept of ‘value’, co-created and
exchanged between actors during a business transaction. The recognition
of value co-creation delivers the concept of a ‘service ecosystem’, in which
multiple actors or business entities are enabled to form a coordinated
arrangement for performing certain services [2].
The dynamic of service ecosystems has stimulated a rapid pace of
change in globalized business environments in which service innovation
becomes a critical priority for business entities. Service providers strive to
provide the best value for customers by optimizing their own service
capability, while at the same time also assessing and forming an alliance
with business partners in order to survive in a competitive service
business landscape.
2
Information Technology (IT) has become an important component in
reshaping services and customer experience in the service industry. It
serves as an important component during customer contact and service
delivery [3]. IT involvement in a service ranges from a simple technology-
assisted contact to an automated self-service contact [4]. Within this
range, the component can assist in a customer contact, as a user interface
channel itself, or as an automated background process in delivering the
service. In these forms, the component takes a central role for service
innovations. New and improved business services deployed with the help
of electronic services are often labelled as an e-service [5].
Considering the dynamic nature of the service ecosystem, the
multitude of service offering concepts, and the pervasive role of IT, the
process of designing a service is not always an easy task. To handle such
an effort, a systematic and structured approach on the service design
process will be helpful. The approach should be able to decompose the
process into smaller manageable parts, while at the same time ensuring
the coverage of multiple aspects of strategic business concepts through
the technical implementation of the IT layer [6].
As the process of service analysis and design becomes a
multidiscipline effort, the elaboration encompasses the domain of
business strategy, business process, IT architecture and software
engineering. Traditionally, each domain discipline had its own
perspective on concept sets and structure. Competing perspectives and
structures may also exist within a specific domain. A similar situation
3
persists in the topic of service engineering. This is the main challenge in
defining a generalized service engineering framework [7][8].
So far, the conceptual foundation for ‘service engineering’ from
industrial or academic works were produced with partial perspective. Two
dominantly competing perspectives are from business-marketing
perspective, and information technology perspective. A unifying
perspective of ‘service engineering’ concept has not been produced. This is
the research gap addressed by this research work by building a
comprehensive and cohesive foundation for service engineering concept.
1.2 Objective and Scope
The objective of this research is to develop a generalized approach to the
process of service analysis and design, with regard to the multidiscipline
nature of the subject matter. To be specific, this generalized approach is
labelled as the General Service Engineering Framework (GSEF).
Table 1.1: Dictionary Definition of ‘Framework’
Meriam Webster Online Dictionary Cambridge Online Dictionary
a basic conceptional structure (as of
ideas)
a skeletal, openwork, or structural frame
a supporting structure around which something
can be built
a system of rules, ideas, or beliefs that is used
to plan or decide something:
The term ‘framework’ is used in this research to moderate the
expected result within the context of ‘Service Engineering’. The intended
4
usage of ‘framework’ stems from dictionary definitions (Table 1.1) which
imply the conceptual nature of the work with an open-ended feature of
the how-to aspect.
Various academic contributors have used the term ‘framework’ as an
umbrella construct to define a way to produce something in various level
of detail, commonly accompanied by a set of base understanding. Table
1.2 collects a sample of ‘framework’ terminology usage in academic
articles. In general, a framework can be summarized as a set of usable
components to pursue a certain purpose.
Table 1.2: Selected Usage of ‘Framework’ Terminology
‘Framework’ Definition Context
Tools for analysing and developing Business modelling [9]
Grouped stages with process and artefacts flow Software engineering [10]
Conceptual model for developing and describing Web service modelling [11]
A set of linked processes as states of the development Design process [12]
Processes guidance with phase definition, tools and theories Service Engineering [13]
Process guidance with common understanding, methods and tools. Requirement engineering [14]
Design and development tools equipped with building block and method Enterprise architecture [15]
Framework departs from the ‘what’ aspect of conceptual
understanding towards the ‘how’ aspect in achieving the purpose. A
framework describes the stages of process flow but occasionally omit the
detailed step normally prescribed in a method.
5
This research supports the definition of framework as an abstract
form of a method [11][16]. A framework could also be seen as a basis for
building a fully prescriptive method by offering a structured system to
realize a targeted objective [17]. Compared to the more rigid and detailed
prescription in a method, a framework allows flexibility in its
implementation, with non-detailed prescription which accommodates
variances in its adoption. This is an ideal feature for an evolving field of
service science, with a diverging taxonomy of service classifications [18].
The targeted framework covers the basic requirement for practical
usage in designing a service system, which includes:
The ‘what’ aspect in the form of concepts definition, structure and
relationship.
The ‘how’ aspect in the form of stages definition, flow of artefacts
and modelling tools.
To stay true as an abstracted form, the ‘how’ aspect of the
framework is presented in a non-prescriptive fashion. While the
framework omits the detail on the ‘how’ aspect, it should still be usable as
a general guide by defining ‘what’ to produce in each step.
The framework covers both the business side and the technological
side of a service system, but the elaboration of service system is focused
onto the provision of a software service, as an implementation of a
service-oriented software system. In focusing on the software service
6
analysis and design, the framework also omits the details commonly
discussed within the context of software engineering.
1.3 Research Problem
As a multidiscipline concept, Service Engineering suffers from the lack of
a cohesive perspective. Various concepts, terminologies and methods
produced competitively within an academic domain, sometimes without
regard to previously available produced context, while other academic
domains may also produce intersecting concepts without a definitive
attempt for a consolidation.
This research is an endeavour to consolidate the multiple
perspectives of Service Engineering by pursuing formal answers to four
research questions within the context of Service Engineering (SvE)
analysis and design:
RQ1: What concepts and component should be covered in SvE?
RQ2: What are the activities to be undertaken during a SvE task?
RQ3: What artefacts should be produced in SvE?
RQ4: In what format should the artefact be presented?
The first research question covers the first requirement of a
framework by defining the ontology for Service Engineering. The next two
research questions cover the ‘how’ aspect of the Service Engineering by
7
defining the stages and produced artefacts. The last research question is
an elaboration of the artefacts by suggesting an appropriate format or
modelling language for each artefact to be produced.
1.4 Research Activities
With an objective of developing a General Service Engineering
Framework (GSEF), the research activity is grounded on the Design
Science Research (DSR) methodology [19]. DSR is characterized by a
research motive of improving an environment by devising innovative
artefacts [20], as illustrated in Figure 1.1.
RESEARCHENVIRONMENT
People(Role, capability,
characterisctic)
Organization(Strategy, structure,
culture, processes)
Technology(Infrastructure,
application,
communication
architecture,
development
capability)
KNOWLEDGE
Foundations(Framework,
theory,
instrument,
construct, model,
method,
instatiantion)
Methodologies(Data analysis,
technique,
formalism,
measure,
validation criteria)
EVALUATE /
JUSTIFIY
(Analytical, case study,
experimental, field study
simulation)
DEVELOP/
BUILD
(Theory,
Artifact)
assess refineDesign
Cycle
Business
needs
Relevance
Cycle
Rigor
Cycle
Application
Applicable
knowledge
Addition
Figure 1.1: Design Science Research Cycles [20]
In DSR frameworks, the environment provides the requirements for
an emergence of a new artefact. In the context of this research, the
requirement takes form as the need for a cohesive view on Service
8
Engineering framework. Therefore, the framework is the artefact to be
built as the research output.
To propose the framework, the research draws from the existing
knowledge base from several appropriate knowledge domains. The
literature survey forms a foundation by identifying available theories,
frameworks, methods, and models relevant to service engineering.
In DSR, the resulting artefact needs to fulfil the acceptance criteria
of the environment to be applicable. In this context, the framework
should be feasible and practical enough to design an intended service
system. A series of case studies is performed to assess the utility and
feasibility of the proposed framework in a practical environment.
Adjustments and additional improvements are made along the conducted
case study to improve the quality of the proposed framework.
A case study is defined as an empirical enquiry which examines a
phenomena, not in an insular academic environment, but within its real-
life context [21]. For the intended service engineering scope, the real-life
context is the process of developing or improving a service system in an
organization. The unit analysis is therefore the service engineering
project with the involved stakeholders.
Two rounds of case studies are performed within this research. As
an initial attempt, the first round of case studies is framed as both
exploratory and confirmatory case study. As an exploratory study, three
service engineering projects were undertaken based on the initial version
9
of the proposed framework to observe the sufficiency of the framework
and the variance developed in the field.
The second round of case study was conducted as a confirmatory
case study. A final case study is explored to assess the coverage of the
proposed service engineering ontology. The case study also validates the
refined framework produced from the first round of case studies.
Phase 3: Concept Refinement
Literature
Review
SOA
Methodologies
Classic Service
Engineering
Service
Engineering
Framework
(1st version)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
SOA
Ontology
Case Study
(Second Round)
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework
(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework
(Generalized)
1 3
42
5
67
Phase 1: Synthesize
Phase 2: Case Study Verification
Phase 4: Enrichment
Software
Service
Ontology
Activity Artifact
#Legend
Sequence
Number
Figure 1.2: Research Flow
In adherence to the DSR framework, the elaboration of the whole
research activities can be grouped into four phases: (1) Synthesis phase,
10
(2) Case Study Verification phase, (3) Concept Refinement phase and, (4)
Framework Enrichment phase. Figure 1.2 summarizes the flow of
research activities.
During the synthesis stage, a literature survey is conducted to
analyse the existing frameworks, to capture general requirement
characteristics of a SvE and to identify components to be incorporated in
the proposed GSEF. The phase will also identify pertinent artefacts and
select modelling tools appropriate for each activity in the framework.
During the synthesis phase, the first version of GSEF is defined to be
tested on the case studies.
In the second phase, the case study verification uses the preliminary
version of GSEF for three separate service engineering cases. Case
studies were conducted within the scope of a municipal level government
service. An evaluation is made for each case to assess the general
feasibility of the framework, to capture the process variance and to
identify previously uncovered important component of the framework. A
consolidated analysis of the case studies results produces the second
version of GSEF.
Towards the end of the second stage, the Concept Refinement phase
is initiated in which another set of literature reviews is conducted. The
goal of this stage is to define the ontological base of Service Engineering.
Two set of ontologies were built: the software-service ontology and
general service ontology. The two are correlated in which the software
11
service ontology is a specialization of general service ontology. To verify
the resulting ontology, a fourth case study was undertaken.
During the final stage, the Framework Enrichment, an examination
is conducted by mapping the framework to the ontology. The goal of this
examination is to assess the sufficiency of the framework coverage in
relation to the general ontology. The mapping also produced the
stereotype of artefact modelling. Equipped with additional literature
survey on existing metamodels, the final GSEF is produced; by proposing
a set of available metamodel to present each artefact of the framework.
1.5 Contributions
The contribution of this research lies in its unique attempt to consolidate
competing and overlapping perspectives of service engineering from both
the business management domain and information system domain. While
the framework addresses the concepts in an abstracted level, its
presentation avoids formalized approach by emphasizing more on a
pragmatic level and strives for simplification. This approach is chosen to
improve the accessibility and practicality of the research result.
The main contribution of this research is the produced service
engineering framework labelled as the General Service Engineering
Framework (GSEF). The framework is presented in a structure of three
layers component: Activity, Artefact, and Modelling. The activity
characterizes the phases and steps of analysis and design process. The
12
artefact defines the output of each step while also implying the
dependency and flow of the produced artefact. The modelling layer is an
open container which suggests the available format to present the
artefact, mostly based on specific modelling language. A combination of
the layered components provides a general perspective in designing a
service system.
As a part of the framework, an ontology set is also produced as a
contribution. The ontology specifies and defines concepts pertinent within
the context of service engineering, along with the defined relationship
among the concepts. Departing from the Information System domain, the
first produced ontology is a Software-Service Ontology. The second
ontology is a generalization of the first ontology which defines generalized
ontology of service system, drawn and consolidated from both the
business management domain and the information system.
As an additional contribution, the research also provides the
landscape of metamodel offering from both industrial and academic circle.
The landscape is a product from exploring appropriate metamodel for
representing an artefact. The metamodel landscape also offers a
stereotype grouping of metamodels and illustrates the relationship
between metamodel offerings.
13
1.6 Chapter Overview
This thesis is organized into six chapters. Figure 1.3 summarizes the
partition of the thesis in relation with the flow of research activities. The
first chapter, Introduction, provides the context of the research by
elaborating the motivation, research objectives, research problems,
research activities, and research contribution.
The second chapter, Literature Review, narrates the exploration into
the available knowledge base relevant to service engineering in
commencing the research. The chapter is divided into three parts; the
classic conception of service engineering from the business-management
domain, the information system domain perspective of service
engineering, and the emerging trend of combining the two perspectives
which create a consolidation gap to be fulfilled with this research.
The third chapter, Service Engineering Ontology, elaborates the
basic foundation of the framework by describing a process of ontology
building from a series of ontologies; from specific software-service
ontology to general service system ontology. The chapter is divided into
three parts: service-oriented architecture ontology, general service
ontology, and software-service ontology. This chapter mainly addresses
the first research question by defining and relating concepts covered in
the framework.
The fourth chapter, Service Engineering Framework, describes the
proposed framework and its refinement process. The chapter exposes the
14
preliminary version of the framework, describes the performed first round
of case studies, and offers the second refined version of the framework.
This chapter addresses the second and third research questions regarding
the stages and artefacts of the framework.
Literature
Review
SOA
Literatures
Classic Service
Engineering
Service
Engineering
Framework(1st iteration)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
Software Service
Ontology
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework(3rd iteration)
Literature Review
Framework (RQ2, RQ3, RQ4) Ontology (RQ1)
Modeling (RQ4)
Ch 4
Ch 2
Ch 3
Ch 5
IntroductionCh 1
ConclusionCh 6
Case Study
(Second Round)
Service
Engineering
Framework(Generalized)
Activity Artifact
Legend:
Chapter
Number
Ch #
Figure 1.3: Research Content Mapping
15
The fifth chapter, Modelling in Service Engineering, provides an
exploration through the metamodel landscape. The chapter demonstrates
the mapping of ontology and framework artefacts as a form of
verification. Finally, the chapter proposes a general form of the
framework by stereotyping the artefacts with a group of relevant
metamodels. Consequently, this chapter focuses on the fourth research
question, regarding artefact modelling.
The sixth chapter, Conclusion, acts as a thesis closure. Summary of
results is provided in the context of research questions. A limitation and
future work section is also provided to reflect and highlight the research
limitation, followed by possible directions for future work in continuing
the research result.
As a summary, this chapter has introduced the motivation of this
research work, along with the selected approach taken in pursuing its
goals. The next chapter is the first step taken in the approach by
exploring existing literatures to examine state-of-the-art, to demonstrate
a research gap and to identify pertinent concepts produced from previous
works for proposing initial service engineering ontology and framework.
16
Chapter 2
Literature Review
2.1 Defining a ‘Service’
Given its nature as a multidiscipline endeavour, establishing a common
paradigm is quite problematic in the service science field. Varying
perspectives arise from different contributors with their own set
paradigm influenced by a particular academic background. Therefore, one
of the challenges in service science is to facilitate an interaction between
various perspectives to define a shared and cohesive perspective [22].
The term ‘service’ carries a broad connotation according to each
domain and context. Therefore, putting down a definitive definition of the
term ‘service’ is not an easy task. In the most generic level, service can be
broadly defined as ‘an act of beneficial activity’ [23]. From this general
definition, a service can already be characterized as having at least four
components: Service provider, service consumer, act of service, and
benefit produced. The third component, the actual act of service,
characterizes the whole process.
In Unified Service Theory, a service is defined as a production
process where the customer possess a role in the process, by providing
some of the input for the particular unit of production [22], as visualized
in Figure 2.1. In a non-service-based process, the design idea of the
17
product may have been contributed by a group of customers, but there
shall be no further involvement from customers in the production process.
After the process, the customer role is limited only in selecting,
purchasing, and consuming the product. This is the key difference
between a service and a non-service process.
Supplier CustomerProduction
Process
Input
Output
Figure 2.1: Service Input-Output Model [22]
All production processes typically require a resource. A
transformative task is performed by the provider consuming the
resources. In a service, the resource can take a non-physical form, e.g.
knowledge, skill, or information. Ultimately, the process produces a
(potential) value to be transferred for the benefit of consumer.
A wider definition of ‘service’ definition is offered in six contexts[16]:
1. Service as an Interaction: an interaction process or event
between provider and client that creates and captures value.
2. Service as a Capability: an ability of an entity to produce an
intangible benefit to its environment.
3. Service as an Operation: a part of an object’s behaviour defined in
a component which can be invoked by a client via an interface.
18
4. Service as an Application: a piece of software accessible over the
web supporting machine-to-machine interaction over a network.
5. Service as a Feature: an additional value offering provided on top
of a basic item, such as in call-forwarding in a telephony system.
6. Service as an Observable Behaviour a set of provider interaction
behaviour externally visible by clients, over an interface.
Four analytical characteristics of service are derived from these six
contexts: (1) involves interaction, (2) provides some value, (3) denotes a
composite or decomposed unit of analysis, and (4) can be abstracted
through a successive design process [16].
In a more pragmatic context of the Service Engineering (SvE)
perspective, the term ‘service’ is used in three different contexts: Business
service, electronic service, and software service [5].
Business Service. In this context the term ‘service’ refers to a generic
definition of the service as a business activity provided by a service
provider to a service consumer to create value for the consumer.
Electronic Service, or e-service in short, is a term used to denote any
service that can be conducted via computer networks, i.e. the
Internet. E-Service can be viewed as a subset of a business service,
for a business service that employs computer networks in the
encounter.
19
Software Service is a type of e-service that can be accessed via web-
based protocols or web-based programs from the consumer side. Web
service, or a collection of it, can serve as a component of an electronic
service.
The three service contexts form a service abstraction hierarchy in
SvE, from business service as the highest abstraction to its technical
form, software service. A higher abstraction can be partly composed from
the lower abstraction. Specific in the IT technical context, i.e. the Service
Oriented Architecture (SOA) perspective, the term ‘service’ usually refer
to the third definition, software service, as a set of implemented logical
process consumable by other software component [24].
The particular scope of this research encompasses the three
definitions, specifically in determining a business service scope and then
decomposing it into several relevant software service components.
2.2 Classic Service Engineering
The growing importance of the service industry motivates many
originally non-service companies, e.g. manufacturing enterprise, to
transform their business model into a Product Service System (PSS). In
this endeavour the product offering is enriched with additional services
through servitization. This trend initiated and stimulates studies in the
service concept [25].
20
The early approaches in developing a service were originally
published under the label of New Service Development (NSD), which was
introduced in the business marketing domain during the eighties [26][27].
NSD is the ‘service’ version of the more established innovation process of
New Product Development (NPD) in traditional goods-based industry
[28].
Departing from service quality research with a focus on customer
satisfaction, NSD emphasizes more on end-user (consumer) services
rather than on the business-to-business (B2B) aspect [6]. NSD studies
typically address particular service development issues, such as service
pre-requisites, service blueprinting, and service development enablers.
Several NSD approaches were proposed as a framework or (partial)
processes without detailed methods and tools for the actual service
development [27].
‘Service Engineering’ (SvE) terminology was coined in the mid-
1990s as a competing term for describing the activity of service
development. SvE is defined as a technical discipline to develop and
design service systematically using appropriate models, methods, and
tools [26]. SvE therefore enlarges the coverage of NSD by accommodating
engineering and software development perspectives in service
development [27]. SvE is also differed from NSD with the inclusion of
business-to-business (B2B) services in its coverage [6].
In a broader context, the term service engineering carry three
connotations: (1) as a systematic design and development task, (2) as an
21
organizational function, and (3) in the context of human resource
management [6]. The first context is often supported with components of
information technology. Therefore, a full scope of SvE concerns with the
design and the development of a service system, composed of: (1)
organizational design aspect, (2) human resources aspect and (3)
information technology aspect [26]. The scope of this research will be
limited to the context of design and development with emphasize on the
information technology aspect. Figure 2.2 summarizes this perspective.
OrganizationHuman
resources
Information
technology
Models Methods Tools
Development of new service products
R&D management of services
Figure 2.2: Areas of Service Engineering [26].
Idea
management
Requirements
analysis
Service
design
Service
implementation
Market
launch
Collection
of ideas
Appraisal
of ideas
Market
requirements
Company
requirements
Service
product model
Service
process model
Service resource
model
Marketing
concept
Service product
implementation
Service process
implementation
Service resource
implementation
Marketing
implementation
Rollout
Customer
feedback
Employee
feedback
Figure 2.3: Stages of Service Engineering [26].
Figure 2.3 shows SvE in its original form. The activities are grouped
into five sequential stages in a waterfall model: (1) Idea generation, (2)
22
requirement analysis, (3) concept development, (4) implementation, and
(5) market launch. Alternatively, the stages can also be designed to follow
an iterative prototype pattern with several cycles of Design-Analysis-
Synthesis activities, before settling into a final master design [26].
Studies and research around service later coalesced into a new
discipline, Service Science, which was later reintroduced as Service
Science, Management and Engineering (SSME) [29][13]. This new
discipline emphasizes on an interdisciplinary approach, combining
management and engineering theories, including concepts from the IT
domain. The underlying motive of this discipline is to advocate a
continuous improvement of the organisation’s competitiveness by
assessing the growing services needs of a business environment [30].
Under this multidisciplinary approach, several service design
frameworks have been proposed. As a multidisciplinary approach, the
framework commonly employs various qualitative analysis tools such as:
Feasibility Study, Socio Techno-Economical Analysis, Environmental
Scanning, Trend Analysis, Boston Consulting Group (BCG) matrix, and
Quality Function Deployment (QFD). Two of such frameworks are
presented here as representative of classic SvE perspective.
A synthesis of service engineering frameworks under NSD label is
provided in [31]. It is structured as a 3-tuple SAT format: Stage, Activity
and Technique. Stage is the highest conceptual level of the methods. A
stage is a container of activity set, while the technique operationalizes the
activity with several instruments or tools for performing the activity.
23
As illustrated in Figure 2.4, the frameworks consisted of 18
activities which grouped into five stages: (1) service identification, (2)
service value net formation, (3) service modelling, (4) service
implementation, and (5) service commercialization stages. Each activity
employs management research techniques, such as survey or Strengths,
Weaknesses, Opportunities and Threats (SWOT) analysis.
Identification1
1.1 Trend analysis: social economy & technology
1.2 Scope analysis: supply & demand side
1.3 Service needs analysis & conceptualization
Value Net Formation2
2.1 Business model analysis (of potential service)
2.2 Service value net analysis & formation
Modelling3
3.1 Product model
3.2 Process model
3.3 Resource model
3.4 Marketing concept
Implementation4
4.1 Service prototyping
4.2 Service testing
Commercialization5
5.1 Service rollout
5.2 Service marketing
5.3 Service monitoring
Figure 2.4: Synthesized NSD Framework [31]
This framework performs ‘Service Design’ process in the service
modelling stage. The service modelling is composed of four components:
product model, process model, resource model, and marketing concept as
in [26]. The UML notation is employed as a tool for the service product
model, while the Service blueprinting technique is suggested for process
24
model. The QFD matrix is proposed as the main analysis tool to relate
customer needs with proposed service characteristics and features.
The NSD framework introduces the Value Net Formation stage as a
special stage for business side analysis of the proposed service by way of
Delphi, SWOT analysis and expert interview. Business model of the
service is developed based on the needs of the consumers and the profits
expectation of the firm. A service value net defines the roles of service
participants with interdependent value proposition relationship.
Another SvE framework is proposed as the Service System
Development Process (SSDP) [32] based on the stages of ITIL
(Information Technology Infrastructure Library) [33], an industrial best
practice of IT Service Management. Figure 2.5 illustrates the framework
with 18 activities grouped into four iterative stages: (1) Service
Need/Strategy/Concept, (2) Service Design & Development, (3) Service
Transition/Deployment, and (4) Service Operation.
The framework divides the service design and development stage
into (1) service requirement analysis, (2) entities and linkage definition,
and (3) service modelling. The service modelling defines (1) functions (2),
interfaces, (3) interoperability, and (4) agreements between participating
entities.
25
Need/Strategy/Concept1
1.1 New service identification
1.2 Feasibility study
1.3 Socio-techno-economical analysis
Operations4
4.1 Service marketing
4.2 Service rollout
1.4 Market concept
Design & Development2
2.1 Requirement analysis
2.2 Service entities & linkages
2.3 Service modeling
2.4 Integrate, Verification & Valildation
2.5 Market development
Transition/Deployment3
3.1 Service prototyping
3.2 Service testing
3.3 Service insertion plans
3.4 Operational readiness
4.3 Customer care
4.4 Service monitoring & quality control
4.5 Life Cycle Management
Figure 2.5: SSDP Frameworks[32]
In its core form, the process of service development within classic
service engineering can be categorized into three major stages: service
planning, service conception, and service implementation [6]. The first
stage, service planning, involves idea generation, formation, and
evaluation. In the second stage, service conception, the ideas are to be
more precisely analysed and detailed, to be implemented in the last stage.
2.3 Service Oriented Architecture
In a related parallel during the emergence of service science and SSME, a
new architectural style of software system gained popularity; the Service
Oriented Architecture (SOA). SOA is formally defined as an approach to
26
manage the distributed capability of different domain ownerships[34].In
the technical context, the capability is encapsulated into a software
service provided by software components.
In the SOA perspective, services are the building blocks of an
enterprise. An enterprise is defined by a service pool, and its interaction
pattern. SOA platform provides a unified mechanism for service offering,
discovery, and interaction. Figure 2.6 visualizes the implementation of
business process as a set of software service components. With this, SOA
promises a better alignment between business process requirements and
IT development processes.
Software
Components
Vacancy
Component
Application
Component
Emp. Record
Component
Career
Component
Software
Services
Recruitment
Service
Employee
Service
Business
ServicesRecruitment Employee
Business
Process
Manage
Employee
Functional
Domain
Human
Resources
Business
Layer
Service
Layer
Component
Layer
Figure 2.6: Elements of Service Oriented Analysis and Design [35]
Conceptually, SOA can be seen as an alignment between of two
classes of enterprise artefacts: Business-oriented building blocks (BoB),
and Technology-Oriented building blocks (ToB) [36]. BoB artefacts consist
of Business Process, Business Event, Business Object, and Business
Functions. A ‘business-service’ is an encapsulated provision of Business
27
Function data transaction into a Business Object, available to be invoked
for Business Process execution. ToBs are implemented in the IT layer to
reflect BoB’s behaviour, where some of the ‘business services’ can be
automated as ‘software services’.
In Software Engineering (SwE) perspective, SOA is seen as a
continuation of component engineering approach [37][38], in which
instead of directly focusing on software components as an end product for
a business, the process is mediated with the conception of business
services and software services.
Service based software is built upon the idea of service reusability
and composition. Several services can be combined to create new service.
The orchestration configuration may be implemented (1) in the user
interface, e.g. client web application, or (2) as a new composite service
component. The services involved in the composition can be: (1) specially
developed for the application, (2) developed within a company for another
project, or (3) from an external provider [37].
The software service interaction is therefore no longer limited
internally within an enterprise. The business landscape can be comprised
of interacting software services among various organizations. These
features are well-suited for the vision of a SSME’s business environment,
the modern approach of SvE, and the demand for flexibility and agility in
service operations.
28
2.3.1 Service Oriented Methodology
Since its inception around 2005, SOA concept experienced rapid growth
from numerous contributors. But up to the point where its popularity
subsides in and around 2010, a cohesive body of knowledge was not
formed. SOA consistently suffers from the lack of a common ontology and
structural definition [7][38]. During this period, numerous methodologies
were offered by contributors to guide the implementation of a service-
oriented system, as Service Oriented Methodology (SOM) [39].
The general objective of SOM is to translate enterprise business
processes to a set of services by providing guidelines, standardized
activities, and techniques. Figure 2.7 illustrates the components of SOM.
It typically consists of two elements: development process, and modelling
language [39]. The development process covers the elements of guidelines,
techniques, activities, roles and responsibilities, verification-validation
mechanisms, quality assurance, metrics, coding standards and tools. The
modelling language element is used to represent produced artefacts in the
development process phases.
Service-Oriented
Methodology
Development
Process
Supportive
Features
Modeling
Language
Service-Oriented
Activities
Service-Oriented
Umbrella Activities
Figure 2.7: Structure of Service Oriented Methodology [39]
29
Table 2.1: An Incomplete List of Service Oriented Methodology
Acronym SOM Name Initiator
1 SOAD Service-Oriented Analysis and Design Zimmermann, 2004 [35]
2 SOSE Service Oriented Software Engineering Karhunen H, 2005 [10]
3 MSOAM Mainstream SOA Methodology Erl, 2005 [24]
4 SDLC Web Services Development Life-Cycle Papazoglou,2006 [40]
5 SEPA SOA Evolutionary Programming Approach Emig C, 2006 [41]
6 SOUP Service-Oriented Unified Process Mittal K, 2006 [42]
7 MSA Methodology for Service Architecture Jones S, 2006 [43]
8 SOAF Service-Oriented Architecture Framework Erradi, 2006 [44]
9 SOA-RF SOA Reference Framework (RF) Allen P, 2007 [45]
10 SOADAS SOAD for Adaptable Service Chang SH, 2007 [46]
11 SOMA Service Oriented Modeling and Architecture Arsanjani, 2008 [47]
12 METS Method for Engineering True SOA Engels G, 2008 [48]
Table 2.1 lists 12 different SOMs collected from academic survey
papers [39][49][50][51]. Some of the obscure SOMs source material may
no longer be available, but two consistently popular SOMs are IBM's
SOMA [47] and Thomas Erl's Mainstream SOA methodology (MSOAM)
[24][50]. For illustrative purpose, these two methodologies are described
in the following narratives.
IBM’s SOMA is a recommended SOA method due to its
comprehensiveness and its vast industrial adoption [51][49]. It covers a
complete cycle of ‘service engineering’, from the business side to the
technical implementation. As can be observed in table 2.2, the method
30
consists of six main stages: (1) business analysis, (2) identification, (3)
specification, (4) realization, (5) implementation, and (6) deployment.
Each stage in-turn consists of three to four sub stages. A complete SOMA
methodology, therefore, can be considered as a SvE framework in itself.
Table 2.2: Stages of SOMA Methodology[47]
1. Business Modeling Transformation
2. Solution Management
3. Identification
3.1. Goal-Service Modeling
3.2. Domain Decomposition
3.3. Existing Asset Analysis
4. Specification
4.2. Subsystem Analysis
4.3. Component Specification
4.4.Refactor & Rationalize Services
5. Realization
5.1. Realization Decisions
5.2. Technical Feasibility Exploration
5.3. Componant Layering
6. Implementation
6.1. Service construction
6.2. Unit Test
6.3. System & Integrat Test
7. Deployment
7.1. Deploy Services
7.2. User Acceptance Test
7.3.Monitor & Manage
4.1.1 Service Flow Specification
4.1. Service Specification
4.1.2 Message & Event Specification
3.2.1 Functional Area Analysis
3.2.2 Process Decomposition
3.2.3 Variation-Oriented Analysis
A variation of SOMA proposes the use of a Component Business
Model (CBM), as a capability analytical tool in the early stage of the
methodology [35]. CBM is a matrix of the enterprise’s business
competencies with levels of accountability, i.e. directing, controlling and
executing [52]. The resulting elements of the matrix are defined as
business components. Each component has the definition of: (1) purpose,
(2) activities, (3) resources, (4) governance, and (5) offered services.
Mostly referred as SOA study material, Thomas Erl’s MSOAM is the
definitive source for understanding SOA concepts. As summarized in
table 2.3, the methodology consists of seven stages of activities: (1)
31
Ontology Definition, (2) Business Model Alignment, (3) Service Oriented
Analysis, (4) Service Oriented Design, (5) Service Development, (6)
Service Testing, and (7) Service Deployment. Despite the seven-stage
process, the reference only explores and elaborates the analysis and
design stages.
Table 2.3: Stages of MSOAM Methodology [24]
1. Define Relevant Ontology
2. Align Relevant Business Models
3. Perform Service Oriented Analysis
4. Perform Service Oriented Design
5. Develop Services
6. Develop Test Service Operations
7. Deploy Services
3.1. Define Business Requirement
3.2. Identify Automation System
3.3.Model Candidate Services
3.3.1. Decompose Business Process
3.3.2. Identify Operation Candidate
3.3.3.Abstract Orchestration Logic
3.3.4. Create Service Candidates
3.3.5. Refine & Apply Service Orientation
3.3.6.Identify Service Compositions
3.3.7.Revise Operation Grouping
3.3.8. Analyze Processing Requirements
3.3.9.Identify Application Service Operations
4.1. Compose SOA
4.2. Design Entity-Centric Business Serv.
4.3 Design Application Services
4.1.1. Chose Service Layer
4.1.2. Position Core Standards
4.1.3. Choose SOA Extensions
4.4. Design Task-Centric Business Serv.
4.5 Design Serv. Oriented Business Process3.3.10. Create Appl. Service Candidates
3.3.11.Revise Service Compositions
3.3.12. Revise Operation Grouping
4.4.1. Define workflow logic.
4.4.2. Derive initial interface.
4.4.3. Apply Service Orientation.
4.4.4. Standardize Service Interface.
4.4.5. Identify Required Processing.
4.5 Design Serv. Oriented Business Process
4.3.1. Review Existing Services.
4.3.2. Confirm Context
4.3.3. Derive Initial Interface
4.3.4. Apply Service-Orientation.
4.3.5. Standardize Service Interface
4.3.6. Add Speculative Features
4.5.1. Map Out Interaction Scenarios
4.5.2. Design Process Service Interface
4.5.3. Formalize Partner Serv. Conversation
4.5.4.Define Process Logic.
4.4.5. Align Interaction Scenarios &Refine
Theoretically, SOA approach can be divided into two strategies: Top
down, and Bottom up [24]. In a top down strategy, the completion of a full
inventory analysis must be achieved prior to the design, development,
and delivery of services. In a bottom-up strategy, a focus is set for a
fulfilment of specific business priority requirements and existing
applications can be used as the starting point for an analysis.
32
By comparing SOMA and MSOAM concept coverage in figure 2.8, it
can be observed that SOM mostly covers the technical part of the
analysis, in detailing the concepts emerged from business process aspect.
In SOMA case, a SOM can also be considered as a SvE framework or a
partial SvE framework integrated with business side analysis [53]. In
this sense, a SOM can also be viewed as a SvE framework with
emphasize on IT perspective.
Business
Domain
Functional
Area
Sub-
system
Business
Process
Sub-
process
Atomic
Activity
Atomic
Task
Service
SOMA
(2006)
MSOAM
(2005)
Business
Goals
Service
(Features)
Existing IT
Assets
Service
(expose)
Service
component
Functional
component
Technical
component
Business
ProcessOperation
Service
ServiceComposition
Service
Layer
Entity
Service
Task
Service
Application
Service
Utility
Service
Business
Service
Capability
Figure 2.8: Comparison of SOMA and MSOAM concepts coverage
2.3.2 Modelling in Service Oriented Analysis
The heart of a SOM is the analysis and design activity which employs
modelling notation. MSOAM framework traditionally uses a simplified
UML class-diagram, in which a circle symbolizes a service, an arrow for
message between services, and tree-like hierarchy for service
33
composition. Other UML notations are also commonly used, e.g. class
diagram, and interaction diagram.
As summarized in table 2.4, six modelling approaches for SOA were
identified: (1) UML, (2) SOMF, (3) PIM4SOA, (4) SoaML, (5) SCA, (6)
SRML [54][55]. Some of these modellings are related: SoaML is an
extension of UML, SRML is inspired from SCA and some of PIM4SOA
concepts were brought forward to SoaML.
Table 2.4: Service Oriented Modelling Language
Acronym SOM Name Initiator
1 UML Unified Modelling Language OMG, 1997 [56]
2 SCA Service Component Architecture OASIS, 2005 [34]
3 PIM4SOA Platform Independent Modelling for SOA Benguria G,2007 [57]
4 SRML Sensoria Reference Modelling Language Sensoria, 2007 [58]
5 SOMF Service Oriented Modelling Framework Bell M, 2008 [59]
6 SoaML Mainstream SOA Methodology OMG, 2009 [60]
Only two of them are still popular as an operational SOA modelling
notation: UML and SoaML. UML notation is often used for modelling a
simple SOA design [61][62]. For a relatively more complex SOA system,
SoaML is suggested [63][64].
34
2.4 Informatics Service Engineering
Besides contributing with the concept of IT Service Management, i.e.
ITIL, in the service sector, IT also provides the concept of Service
Orientation in computing and enterprise architecture. With the advent of
SOA, enterprises were drawn to adapt their enterprise applications into a
service-oriented system, to increase the business agility.
Figure 2.9: Scientific Publication of ‘Service’ Modelling [65]
With the growing pervasiveness of IT in service industry, especially
in providing e-Services, the study on SvE gained momentum in the IT
field. This trend can be observed from the number of SOA related ‘service’
publications as visualized in graph of figure 2.9. The trend grew
exponentially around 2003 before reaching its peak in 2009 and
experienced downward trend afterward [65]. More recent academic
studies on SvE tend to be produced by IT contributors with a tight
conceptual relation with IT components.
35
In the context of e-service, the SvE is defined as an approach of
using models and techniques in guiding the sequential process of e-
service conception, analysis, design, implementation, deployment,
operation, maintenance or modification [5]. Within this scope, the
objective of the SvE framework is to provide services in the IT layer,
specifically in the form of web services which will allow a degree of
automated interaction among software component.
2.4.1 Service Engineering and Software Engineering
Differences between SvE and SwE were explored long before SOA
concepts gained traction in [66]. Two identified differentiators are in the
(1) life-cycle, and (2) stakeholder. Service development and deployment is
commonly performed in an environment with continuous system
maintenance, change and enhancement process. Software product in the
other hand normally has a life-cycle in more traditional sense.
The second difference is that unlike SwE, which normally has only
one responsible organization for system deployment, SvE often involves
more than one organisation in a service deployment [66] in forming a
multi-provider service system from a ‘service ecosystem’ [2].
SvE introduces new roles traditionally not discussed in traditional
SwE, i.e. service provider, service requester and intermediaries [8].
Therefore, software services are not always designed and built for one
36
particular business unit but can also take into account the exposure
potential for others in a totally new business context.
Additionally, software service development introduces a new concept
of ‘dynamic service binding’ to support runtime collaborative processes.
But to enable this, a mechanism of automated service discovery, service
selection and service invocation is required in the service system [8].
While the development of software services can be seen as a special
case of SwE, SvE normally covers a wider context of analysis in
identifying services by taking consideration of an enterprise-scale
business process and application architecture [8]. In terms of SOA
adoption, SvE is seen as a higher abstraction of a software engineering
process. If the specific objective of software engineering is a (software)
system, the objective of SvE is more of an enterprise-wide business
service system.
2.4.2 Service Engineering and SOA
Incorporating SOA into classic SvE has been naturally proposed. An early
proposal for including SOA in SvE is found in [13], as detailed in table
2.5. The proposed SvE framework consists of three stages: Requirement
Identification, Service Design, and Service Delivery. SOA approach is
integrated into the second phase, Service Design, as service technology
that provides principles and governing concepts for systems development
and integration. SOA is employed for its ability to combine several
37
functionalities to form ad-hoc applications that can be built almost
entirely from existing software services.
Table 2.5: Service Engineering Framework with SOA [13]
Stage Name Brief Description
Requirement investigation
Quantitative Questionnaire Close-formed market research
Qualitative Kano Classify customer preferences to five categories
Interpretive Method Customer club, personal interviews
Behaviour Observation Direct observation of human behaviour for design requirement
Critical Theory Customer complaints, feedback of lost customers, call centre
Complaint Analysis Investigation of complaints
Focus group, Delphi, other Meeting forms etc
A group of people are asked interactively about their attitudes towards a product or service
Critical Incident Technique
Identifies critical significance activities
Service Designing
System SOA Architecture IT architectural approach integrating business as linked, repeatable business tasks, or services
Process Service Blueprinting Describes detailed service implementation
House of Quality Graphic tool to define the relationship between customers’ desires and the firm’s capabilities
Service QFD Quality approach in designing based on customers’ need and values
Service FMEA Identify potential failure modes, determine their effect, and identify mitigative action
Service Delivery & Improvement
Test Service Prototyping Prototyping for user testing
User Satisfaction
Satisfaction Questionnaires
Ex-post analysis of customer satisfaction
From an IT perspective, SvE is often analogous with SOA adoption,
in which (software) services are developed for reuse in service oriented
applications [37]. Figure 2.10 illustrates SvE as a service-orientated re-
engineering of an enterprise-wide system in [67]. The process is
performed by aligning the layers of (1) Business Model, (2) Business
Architecture, and (3) IT Architecture. SOA resides in the IT architecture
layers as a resource providing infrastructure services. In turn, the
38
technological changes brought by SOA allow for new business strategies
and adjustment, which eventually can also stimulate service innovation.
Business
Model layer
Business
Process
Application
Portfolio
IT Infrastructure
Business
Architecture
layer
IT
Architecture
layer
Stakeholder
perspective
Financial
perspective
Activity
perspective
Resource
perspective
Cost Benefit
Value
Proposition
Customer-Centric
Arc
hite
ctu
re A
lign
me
nt
Go
ve
rna
nce
SOA
Service
Innovation
Enterprise
ArchitectureBPM & ITSM
Figure 2.10: Business-IT Alignment Model Framework [67]
A more detailed description of the role of SOA in SvE is provided by
[53]. A SvE framework is proposed under the name of a ‘consolidated
approach for business and software services identification and analysis.
The proposed framework divides the approach into two parts: (1)
derivation of a business service and (2) derivation of software services.
Both parts are composed of three stages: (1) preparation stage, (2)
identification stage, and (3) detailing stage. A fourth stage, prioritization
stage, is added in the end of the first part, connecting the two parts.
39
Non-technical
SOA design
Develop
SOA strategySOA strategy
Establish business
ontology
Establish
Information base
Suitability
analysis
Interviews
Interviews
Executive report
SOA value driver
Business ontology
Revised set of
business artifacts
Business vision
& strategy
Analysis external
environment
Business artifacts: - Enterprise archit. models
- Stakeholder document
- Process model
- Organization chart
- Application document
Revised set of
business artifacts
Design principle
Capability analysis
Service identification
Interviews
Hierarchy of
capabilities
Hierarchy of
business services
Hierarchy of
business services
Revised set of
business artifacts
Define interaction
model
Define operation
model
Define service
specification
Define resources
Define underlying
processes
ACTIVITIESINPUT OUTPUT
PR
EP
AR
AT
ION
ST
AG
EID
EN
TIF
ICA
TIO
N S
TA
GE
DE
TA
ILIN
G S
TA
GE
Business context
Existing
vocabularies
Identify business &
IT imperatives
Interviews
Identify interactions
Define attibutes
Define domains
Stakeholder analysis
Analyse entities
& interactions
Interaction
analysis
Model of interacting
business services
Stakeholder per
business service
Define underlying
contract
PR
IOR
ITIS
AT
ION
ST
AG
E
Model of interacting
business services
Define non-financial
measures
Interviews
Define financial
measures
Value analysis
Financial reports
Business context
Business vision
& strategy
Foundation for
sourcing and
funding decission
Classified business
services
Figure 2.11: Derivation of Business Service [53]
Figure 2.11 visualizes the derivation of business services, as a top
down analysis to produce a hierarchy of identifiable services. At the end
of the detailing stage, a model of interacting business services is
formalized as a ‘non-technical SOA design’. The business services are
40
later prioritized to determine services to be enabled with software
services.
Define scope for
service enablement
Subset of
business services
Application
analysis
Process
decomposition
Suitability
analysis
Interviews
Interviews
Process-to-
application mapping
Application
characteristics
Functionalities
and components
Decomposed
processes
Suitable process for
service enablement
Classified
business services
SOA strategy
Business artifacts: - Enterprise archit. models
- Stakeholder document
- Process model
- Organization chart
- Application document
Processes for
service enablement
Service design
principle
Entity analysis
Process analysis
Visibility & interaction
analysis
Entity services
Task services
Utility services
Process services
Subset of
business services
Stakeholder fo
business service
Tech. SOA design
Service design
principle
Functionalities &
components
Verify services
Detail operations
Mapping
Establish/Update
service inventory
Adapt existing
services
Existing services
New services
Revised tech
SOA design
Draft of
SOA design
Service
inventory
Technical SOA design
ACTIVITIESINPUT OUTPUT
PR
EP
AR
AT
ION
ST
AG
EID
EN
TIF
ICA
TIO
N S
TA
GE
DE
TA
ILIN
G S
TA
GE
Figure 2.12: Derivation of Software Service [53]
The derivation of the software services part in figure 2.12 uses a
meet-in-the-middle approach by taking into consideration the legacy
system to be juxtaposed with required (atomic) software services for a
41
‘technical SOA design’. During the identification stage, the potential for
composition and consolidation of services is also analysed.
In the detailing phase, a decision must be made if the existing
software service should be extended or adapted. Services are specified to
avoid overlapping and to make it more reusable and autonomous. The
resulting services are then published in a service inventory.
This consolidated approach embodies the purpose of SvE in
identifying services that may be provided on the business and technical
levels. The approach covers an end-to end process of mapping business
services to software services. The work clearly suggests that SOA can be
an integral part of SvE in the case of software-service provision.
From these examples of IT perspective frameworks in [67][53], SvE
can be viewed as a broad process of applying service orientation analysis
to an organization, or implementing the SOA approach in the enterprise.
This view is also supported in the software engineering domain [37].
As an approach of adopting SOA, the framework addresses more on
the issue of business-IT alignment, rather than creating a new (business)
service [68]. Service innovation is an additional result brought by the
increased agility.
2.5 Research Opportunities in Service Engineering
Despite the research contribution over two decades, Service engineering
(SvE) is generally still regarded as an unfinished research challenge in
42
the literature due to mostly partial and fragmented approach taken
[7][8]. A gap still exists in consolidating the perspectives related to the
multi-discipline nature of service science discipline, especially to answer
the dynamic future of service ecosystem [27].
To date, various SvE frameworks have been proposed. In its original
conception, SvE is defined as a process of identifying and developing
newly conceived business services [31][26][32]. Most of the frameworks
reside in an abstract level by focusing on value propositions instead of
conceptualizing the targeted service systems.
The emergence of smart device and contextual data suggests that
the future of service innovations lies in the recombination of service
offerings, where the innovation is not solely derived from an internal top-
down process, but also by considering resources and solutions supplied by
different service participant in forming a collaborative network and
virtual organization [27][69]. Current SvE frameworks mostly still
neglect the prospect of a multi-provider service system [27].
The dominant use of service blueprinting in the classic SvE stream
might be insufficient to portray the formation of a multi-provider service,
the detailed back-end process, and the involvement of IT components. The
incomplete model may compromise the quality of the service development
process.
In the technological perspective, influenced by service-orientation,
SvE is positioned as a top-down analysis process of an existing enterprise
business service structure to be translated as software services in an IT
43
infrastructure [67][53] as in the SOA approach. The goal is to improve the
business-IT alignment and the agility to introduce new service
innovations.
In this technical perspective, SvE often takes form as Service
Oriented Methodologies (SOM). Unlike the case in Software Engineering,
where certain methodologies become popular and dominant, e.g. RUP or
Agile, SvE experiences a continuous proliferation of SOM, while none of
them can be considered comprehensive and integrated enough to cover
both business and software services [53].
A comprehensive service engineering methodology is therefore
expected to provide an integrated approach to cover both the business
side and the software side of services, to ensure business-technical
alignment, and to improve process agility.
Classic
Service
Engineering
Informatics
Service
Engineering
SOA
Methodology
Software
Engineering
General
Service
Engineering
New Service
Development
Figure 2.13: Context Positioning of Research Scope
The positioning of this research is visualized in figure 2.13. The
research attempts to consolidate the two perspectives of SvE for specific
business services innovations, as originally defined in classic SvE. The
44
proposed framework focuses on specific business services analysis and
design rather than assessing the whole of service provider’s capabilities.
The research covers the aspects from service business needs to
derivation of software services. The goal is not to devise the service-
oriented software system, but to identify applicable software service
accommodating transaction interactions.
In elaborating the result of a literature survey, this chapter has
explicitly demonstrated an academic necessity and a research gap to be
fulfilled by this research work. In the same time, the chapter also collates
relevant previously proposed concepts to be collected in building the
research target, i.e. the ontology and the framework. This collation of
relevant concepts is to be elaborated in the next chapter by identifying
components related to the ‘service engineering’ concept to define an
ontological basis for service engineering framework.
45
Chapter 3
Service Engineering Ontology
3.1 Ontology Defined
‘Ontology’ departed as a branch of philosophical study in the 17th century
which explores the concept of ‘existence’ [70]. As a study, it concerns with
the conceptualized abstraction form of nature’s entities and their
relationship. From this philosophical root, the term ‘ontology’ is defined
as a set of structured (abstract) concepts within a defined domain. The
structure may consist of categorization, attributes and relation between
concepts. It serves a basis for a language, to be used as a communication
tool to share an understanding regarding a specific domain.
Due to its capability in abstracting a real-world system, the term
‘ontology’ was later adopted by computer and information science in the
20th century [70], first in data modelling and later as ‘domain ontology’ in
artificial intelligence domain. In this pragmatic level, ontology is
constrained as the definitions and inference rules for a set of words. The
definition represents the concepts, while the inference rules define the
relations between concepts.
Ontology is tightly related to modelling activity. A ‘model’ is defined
as a representation of a reality within a definite purpose. To facilitate a
common understanding between multiple parties, a model is usually built
46
based on a specific modelling language, i.e. metamodel. The metamodel
specifies a palette of concepts and constraint rules for a valid model for a
specific modelling language[71].
Figure 3.1 describes the relation between an ontology and a model.
Ontology is an explicit and formal specification of a shared
conceptualization, in both model and metamodel level. Two types of
ontology are therefore involved: (1) ontology of meta models, and (2)
ontology of problem domain, or a ‘domain ontology’ [72]. A model is an
instantiation of a ‘meta model’ and similarly, a ‘domain ontology’ is an
instantiation of a ‘meta model ontology’. Both model and metamodel are
semantically interpreted by their respective ontology.
Meta-
model
Model
Metamodel
Ontology
Domain
Ontology
‘Reality’
Semantic
relation
Semantic
relation
Instatiation Instatiation
Abstraction Abstraction
Abstraction
Syntactic
domain
Semantic
Domain
Abstraction
Figure 3.1: Model, Metamodel and Ontologies [72]
A shared common understanding is essential within a collaborative
effort. During the construction of this research objective, i.e. “Service
Engineering Framework”, a series of ontologies is developed. As the
framework is a container for development activity, the ontology built is in
47
the ‘metamodel ontology ’level. The idea is to juxtapose the ontology with
metamodel usage during each analysis and design activity.
Two ontologies are presented in this chapter: (1) Software Service
Ontology and (2) General Service Ontology. The first ontology is built
from the relatively established SOA stream, which is later adapted and
generalized to cover non-technical perspectives originated from classic
service engineering. Figure 3.2 provides a map of this chapter in the
context of the overall research flow presented in figure 1.3.
Related Service
Ontology Work
SoaML
Exploration
SoaML
Ontology
Table 3.2
Figure 3.10Service Ontology
Exploration
and Definition
ISO/IEC SOA
Ontology
(General)
Service
Ontology
Table 3.22
Figure 3.12General vs
Software Service
Delineation
Software Service
Ontology
Table 3.24
Figure 3.14
SOA
Literatures
Sec 3.4
Sec 3.2Sec 3.3.1
Sec 3.3.2
Sec 2.3
ISO/IEC, OMG
Standards
Specification
Sec 3.4.1
Sec 3.4.3
Software Service
Ontology Stream
General Service
Ontology StreamLiterature
Review
SOA
Literatures
Classic Service
Engineering
Service
Engineering
Framework(1st iteration)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
Software Service
Ontology
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework(3rd iteration)
Literature Review
Framework (RQ2, RQ3, RQ4) Ontology (RQ1)
Modeling (RQ4)
Ch 4
Ch 2
Ch 3
Ch 5
IntroductionCh 1
ConclusionCh 6
Case Study
(Second Round)
Service
Engineering
Framework(Generalized)
Activity Artifact
Legend:
Section
Number
Sec # Figure #.#
Artifact
Number
Figure 3.2: Research Flow and Content Map (Chapter 3)
48
3.2 Related Work
As mentioned earlier, service science still experiences a lack of standard
ontology for ‘service’, and ‘service system’ concepts. Recent service
engineering studies mostly emerges from IS/IT contributors with a useful
perspective on ontology. While the volume is lower than the SOA
methodology offerings, several ontology propositions do exist. Several of
such works is summarized here.
Figure 3.3 is one of early attempts in defining a service ontology, as
a service system metamodel, within the context of a SOA methodology
[73]. The simple abstraction only covers nine components. While the focus
is on software-service, it already relates to one non-IT concept: business
process.
Service
Consumer
require
Target
Service
Service
Provider
Publishable
Service
provide
satisfy
Service
Interface
Service
Componentconform
Composite
Service
Atomic
Service
Business
Processrealizeconform
provide
consume
Scope of
Service System
Figure 3.3: Metamodel of Service System [73]
49
In this ontology, service is differentiated based on participant type:
(1) For service consumers, a service is a unit of expected functionality
with a service level agreement as ‘Target Service’. (2) For service
providers, a service is a unit of deployed functionality as ‘Publishable
Service’. ‘Service Interface’ serves as a front-end for ‘Service Component’,
which can be in an atomic or a composite form.
Behaviour
Interaction
contributionInteraction
Role User RoleProvider
Role
Offered
Service
Requested
Service
ServiceChoreography
Orchestration
Interface
representsrepresentsrepresents
2..*
1..* 1..* 1..* 1
2..*
1..*
*
*
*
Figure 3.4: Metamodel of Service Concept [16]
Another ontology proposition from software service-orientation
perspective is found in [16]. It defines three successive abstractions of a
service: (1) single interaction, (2) multiple interactions (choreography),
and (3) multi-provider (orchestration). Five overlapping aspects of a
service model were also defined: (1) structure, (2) behaviour, (3)
information, (4) goal and (5) quality. The structural aspect of a service is
conceptualized as a metamodel covering 12 concepts, entirely from a SOA
perspective (figure 3.4.).
50
Figure 3.5 presents SOA metamodel proposed by CBDI [74], a
consultant firm known as an active participant in Object Management
Group’s (OMG) SoaML initiative. The metamodel already covers the
concept of ‘capability’.
Service
CapabilityResourceneed
Policyconform
Participant
realize
BehaviorInter
Service
Relationship
Service
Interface
Operation
provides
provides
has
has
Interaction
Protocol
Message
Type
uses
access
Service
Depedency
com-
pose
Figure 3.5: Service Package of SOA Metamodel [74]
An enrichment of CBDI’s SOA metamodel is proposed in [75].
Within a service engineering process, a business modelling activity is
followed by a service modelling. The service is specified based on five
components: (1) inner structure, (2) interface, (3) operation sequence, (4)
information type, and (5) contract.
This notion of service components is also reflected in the business
level. A business service can be seen as an aggregation of overlapping
components such as: (1) underlying process, (2) contract, (3) owner, i.e.
providing participant, (4) exposed operation, i.e. interface, (5) operation
model, i.e. operation sequence, an external interaction model, i.e.
interface and contract [53].
51
As an attempt to consolidate the non-orthogonality of competing
SOA concepts, a literature survey on SOA concepts is performed in [38]
and presented in table 3.1. Nine core identifiers which characterize a
service-orientation are extracted: (1) architecture, (2) binding, (3)
capability, (4) composition, (5) contract, (5) delivery, (6) distributed
sources, (7) identity, and (8) interoperability. Further attempts to
operationalize these characteristic into service modelling did not lead to a
ontological view of SOA or service [62].
Table 3.1: SOA Characteristic Identifiers [38]
No Identifier Description Related Terms
1 Architecture Overall system organization built from services elements, interacting through a mechanism
Architectural paradigm, architectural style, software architecture
2 Binding The time at which a particular service (and provider) is chosen.
Agility, dynamic binding, flexibility, loose coupling, on demand
3 Capability The purpose of an SOA as viewed from an end-user perspective
Business functions, resource management
4 Composition The assembly process of services set to provide a single service that meets a need.
Choreography, integration, orchestration, service composition
5 Contract The agreement mechanisms for the terms and conditions for delivered service
Service contracts, service negotiation
6 Delivery The process where service functionality is supplied by the service providers the needs.
service interaction, service invocation, service provider, service consumer
7 Distributed Sources
Delivery across network, owned and controlled by different parties
different ownership, distributed system architecture, network environment,
8 Identity Description characteristic of a service and the means of access.
service description, service discovery, service publication, service registry,
9 Interoperability Service deployment masks location and technical details
interfaces, platform independence, standards, messaging protocols
10 Packaging Unique and distinct identity characteristic of service implementation
component, granularity, reusability, self- containment, web services
From these previous works, selected concepts that can be considered
as potential components for targeted ontology are: (1) architecture, mostly
for software level abstraction, (2) binding, related to ‘role’ concept, (3)
52
capability, (4) composition, related to atomicity or composite nature of
service, and (5) contract. Additionally, structural modelling for a service
is defined to be consisted of: (1) service operation, (2) service component,
and (3) service interface [62].
3.3 Software Service Ontology
As demonstrated in [62], integrating SOA concepts from individual
contributors is not always a feasible and usable approach. A more
practical approach is hence taken to use collaborative SOA standards as
the source for ontology building. Over the years, several standard groups
have produced SOA open standards: OASIS, The Open Group, OMG and
ISO/IEC.
The standards published is not always compatible to each other, and
actually competing in its overlapping terminology [76]. As illustrated in
figure 3.6, two products can be considered as the state-of-the-art: (1)
OMG’s SoaML, as the definitive SOA metamodel originated from OASIS
stream, and (2) ISO/IEC’s SOA Reference Architecture, as the latest SOA
ontology definition originated from The Open Group stream.
Ideally the two should be related semantically, in which the (SoaML)
metamodel uses the concept defined in the (SOA-RA) ontology [72]. In
reality, that is not the situation due to the difference in the originating
sources. Therefore, these two products are treated separately in this
53
research as sources for the Software Service Ontology. Comparison is
performed between the two as a research triangulation.
OASIS
SOA Ref. Archit (2008)
The Open Group
SOA Ontology (2008,2010)
OMG (ADTF)
SoaML (2009, 2012)
The Open Group
SOA Ref. Archit. (2011)
OASIS
SOA Ref. Model (2006)
influence
ISO/IEC (18384:2016)
SOA Ref. Archit. (2016)
Adopted into
Partially
Adopted by
Detailed into
(minor)
Influence
(minor)
Influence
(minor)
Influence
Figure 3.6: Succession of SOA Open Standard [76]
3.3.1 Ontology of SoaML
SoaML was first formalized in 2009, with minor updates later in 2012
[60]. SoaML is conceived based on the limitations of UML in representing
SOA concepts [63]. While its popularity in the industry is very limited,
SoaML is consistently referenced in academic publication as the
definitive metamodel for SOA [64][77]. Table 3.2 lists SOA concepts
covered by SoaML.
SoaML can be seen as an ‘agnostic’ metamodel for SOA. The
specification offers options to be decided by the modeller to cater a broad
range of SOA implementation types, from simple SOA, e.g. flat REST-
54
based web-services, to complex hierarchical SOA, e.g. SOAP/WSDL-based
with a centralized service bus.
Table 3.2: SoaML Conceptual Components [60]
No Concept Description SoaML Representation
1 Participant Entities (physical or software) that provide or use services
Participant (ports and interfaces container), part of service architecture
2 Port Participant’s service interaction points in providing or consuming services
(Small square) Part of participant, might contain (interface) spoke or socket
3 (UML) Interface
A type of service interaction description for synchronous unidirectional interaction
(UML) Interface, might be part of Service Interface diagram, spoke or socket in participant diagram
4 Service Interface
A type of service interaction description for (multiple) asynchronous interaction
Service interface diagram, might contain several (UML) Interface
5 Service Contract
A type of service description based on roles and rules as an agreement for multi-party interaction
Service contract, might be part of Service Architecture, might contain several (UML) Interface
6 Capability Ability owned, or required, by participant to affect some changes.
Capability diagram
7 Role A specific functionality assumed by participant in an instance of service interaction
A label in Service Architecture, Service Contract, and Interaction Protocol
8 (Role) Binding
A pairing instance of a participant with a role within a specific service interaction context
(Instance of service contract, contact of participant’s spoke and hub)
9 Interaction protocol
(Sequential arrangement of operation invocation between role/interface)
UML behaviour diagram as part of service interface, or service contract
9 Operation (An atomic invokable software behaviour with input-output message passing feature)
Labelled component in Interface, or labelled invocation in interaction protocol
10 Message type Data values that can be sent between participants
Message type, might be related to (UML) data type and entity attribute
11 Service Architecture
High level description of connection between participants through service contracts within a specific service community
Service architecture: contains participants, service contracts, and role-labelled connectors
12 Method Owned behaviour of a participant UML behaviour of participant describing its inner behaviour
While providing a formal specification of its stereotyping extension
from the original UML specification, SoaML document specification is
surprisingly lacks an ontological definition. SoaML specification actually
offers two types of service modelling approaches: (1) Interface-based and,
55
(2) Contract-based [60][78], and therefore multiple forms of service
abstraction is permissible [77], [79].
Apart from the OMG’s specification document, the availability of
SoaML reference material is quite limited. The combined factor of the
complexity, the multi-interpretative characteristic, and the limitation of
source forms a barrier for entry in SoaML exploration. With the declining
trend of SOA popularity as a terminology, this may contribute to its lack
of adoption in industrial cases.
A peculiar feature of SoaML is the absence of specific abstraction for
‘service’. Three abstractions are offered superimposed to service
description components [60] as:
1. Interface, accommodating atomic services containing only self-
contained operations
2. Service Contract, accommodating atomic services and composite
services by combining interfaces into a service contract.
3. Service Interface, accommodating atomic services and for composite
services by combining interfaces a service interface.
Consequently, there are three versions of an ontological structure
that can be inferred from the specification: (1) Interface-based, (2) Service
Contract-based, and (3) Service Interfaced-based. These versions are
elaborated in the following paragraph. To simplify the visualization of the
differences, a special technique is employed where: (1) Compositional
56
relationship is visualized in the form of a Venn diagram, whereas
components are placed inside a container representing the compositional
parent, (2) the service abstraction is visualized with a thicker border in
the superimposed service description component.
Figure 3.7 visualizes the first version in which ‘service’ abstraction
is superimposed to the (UML) ‘interface’ concept. The approach is used for
simple SOA where the whole architecture is composed of flat atomic
services without the possibility of a service composition. Each interaction
is synchronous involving exactly two participants with an interface
embedded with a specific role; either as a service requester in a consumer
role or as a service responder in a provider role.
Service
Architecture
Service
Contract
Participant
Interface(Atomic Service)
Method Port
RuleOperation
Association
(1 to 1)
Association
(1 to 1)
Depedency
(1 to 1)
Compositional
relationship
Service
abstraction
Role
Figure 3.7: Interface-based Service version of SoaML Ontology
57
Service
Architecture
Service
Contract
Participant
Interface(Atomic Service)
Method Port
Interaction
Protocol
OperationAssocation
(1 to 1)Rule
Role
Association
(1 to 1)
Aggregation
Aggregation
Depedency
(1 to 1)
Compositional
relationship
Service
abstraction
Figure 3.8: Contract-based Service version of SoaML Ontology
Figure 3.8 visualizes the second ontological version, in which a
‘service’ is abstracted with the ‘service contract’ concept. Service contract
is equipped with an interaction protocol as an internal logic that governs
invocation sequences, both synchronous and asynchronous, between
participants. The approach is able to accommodate a service interaction
with more than two participants. Service composition is possible in the
form of a compound service contract [60][78].
58
Service
Architecture
Participant(s)
Service Interface (Composed Service)
Interface(Atomic Service)
Method Port
Service
ContractRule
Role
Interaction
ProtocolOperation
Depedency
(1 to 1)
AggregationAssociation
(1 to 1)
Association
(1 to 1)
Association
(1 to 1)
Compositional
relationship
Service
abstraction
Figure 3.9: Service Interface-based Service version of SoaML Ontology
Figure 3.9 illustrated the third version of the ontology, where
‘service’ is abstracted as both ‘interface’ (for atomic service) or ‘service
interface’ (for composite service). Service interface has an interaction
protocol as an internal logic to govern invocation sequencing in both
synchronous and asynchronous invocation between participants. Service
interface can also accommodate an interaction service with more than
two participants. Service contract can be omitted if there is no need for
service invocation rules.
There is no evidence to support the ability of a service interface to
refer to another service interface. Therefore, only one level of service
composition is assumed possible. SoaML is very unrestrictive in
specifying service composition techniques. Apart from using the service
contract or service interface as an abstraction of a composite service, a
composition can also be modelled at the participant level (i.e. component)
by defining sub-participants interaction inside a super-participant.
59
Theoretically, there is a fourth version in which the three options
are combined, where a service can take the form of an interface, service
interface or service contract within a single design context. But this may
lead to an inconsistency and unnecessary complexity. In this attempt to
be implementation agnostic, the unrestrictive specification makes SoaML
a complex and a rather confusing modelling tool.
To simplify the SOA ontology building, a specific SoaML perspective
is prescribed. By considering to the availability and popularity of a
practical SoaML guidance material in [77], which adheres to the service
interface-based approach, the third version of the ontological structure is
selected. The SOA ontology is therefore presented in the figure 3.10 as a
reformulation from similar relationships in figure 3.9. Concept definitions
are consistent with the previously listed table 3.2.
The produced ontology covers most of the components mentioned in
the section 3.2. The components are mostly abstract design concepts,
except for three components: (1) participant, to become some form of
software component, (2) simple interface and (3) service interface to be
implemented as an atomic or a composite software service, e.g., web
service and WSDL interface.
60
Service
Architecture
Service
Contract
Participant
Service
Interface(Composed service)
Method
Message
Type
Interaction
Protocol
Capability
Port
Role
Composed
of
‘Service‘
Can be
detailed into
Use or
Realize
Part of
Simple
Interface(Atomic Service)
Realize
has
Expose
Perform(Request/
Provide)
Operationhas
Parameter
has
Use
Govern
Arrange
Figure 3.10: SoaML Ontological Structure
Considering the fact that the paired component (e.g. Participant vs.
Software Component) is actually the same object in different stages of the
engineering process (i.e. design vs. implementation), the implementation
instance of ‘component’ is not included in the ontology.
3.3.2 ISO/IEC SOA Ontology
Apart from the SoaML minor revision in 2012, ISO/IEC 18384:2016 (SOA
Reference Architecture) [80] is a rare example of SOA standard published
after SOA popularity decline in the 2010s. In actuality,
ISO/IEC18384:2016 is mostly based on two previous products of The
61
Open Group: SOA Ontology (2010), and SOA Reference Architecture
(2011).
Table 3.3: ISO/IEC 18384:2016 SOA Conceptual Components [80]
Concept Description
1 Element Unit at a given level of abstraction with a clearly defined boundary.
2 System An organized collection of Element instances
3 Entity Individual Element of system which can act as a provider or consumer
4 Actor Person or system component that interacts with the system.
5 Service Logical representation of activities set with specified outcomes
6 Atomic Service A self-contained service
7 Composite Service An assembling of other services to provides a higher-level service.
8 Architecture Fundamental concepts of a system (elements, relationships, design principles)
9 Endpoint Location at which information is received to invoke and configure interaction
9 Capability An ability possessed by an Element as a basis for service offering
10 Interface Shared boundary between two units (functions, interconnections and exchanges)
11 Service interface Interface by which other elements can interact and exchange information
12 Service Contract Terms, conditions, and rules that interacting participants binded to agree on.
13 Role An activity set assignable to an entity for a specific function in an interaction.
14 Information Type Information provided to or receive from upon service usage
15 Task atomic action which accomplishes a defined result
The standard formally defined 61 concepts. A selected subset of the
components is listed in table 3.3. An inconsistency is found in the
standard. The definition part is not fully correlated with the provided
ontology structure. The defined ontology only covers 14 concepts (figure
3.11) without mentioned detail on the other concepts.
The ontology is quite simple, and its coverage is superficial if
compared to SoaML ontology. The coverage is lacking in a detailed level
of (software) service abstraction, i.e. port, operation, role, and interaction
protocol. The ontology is also missing some of the key concepts defined in
the terminology part, i.e. Capability, Service Architecture, and Role.
62
ElementService
perform
SystemService
Interface
has
Compo-
sition
Service
CompositionProcess
Information
Type
Service
Contract
Effect
specify
has
Human
ActorTask
performPolicy
set
Event
Party of
Generate
Respond
OrchestratePart of
has I/O
apply
Figure 3.11: ISO/IEC 18384:2016 SOA Ontological Structure[80]
Despite these differences, correlation with SoaML ontology occurs
in: (1) Service Interface, (2) Service Contract, (3) Information Type, and
(4) Element (Participant in SoaML). The relationships are also consistent:
Element perform Service (via Port and Role in SoaML)
Service has Service Contract and Service Interface as service
description
Service Interface has Information Type as attribute (via Operation
and Parameter in SoaML
It can be observed that the previously produced SoaML ontology
(figure 3.10) is relatively consistent with the other software service
ontologies. It is also a superior ontology compared to the ISO’s ontology in
coverage and level of detail. The produced SoaML ontology is therefore
established as an intermediary for a true Software Service Ontology.
63
3.4 General Service Ontology
Similar to the fact that SoaML and UML are only used within the context
of designing a software system, SOA is rarely discussed beyond the
context of software architecture. Even though the adoption of service-
oriented concepts is not apparent beyond the technological sphere, its
conception always strives to provide a generalized abstraction covering
both IT-based and non-IT-based systems.
While in reality, the distinction for IT and non-IT context of a
service system needs to be made, the generality feature of SOA
conceptions is useful to build the General Service Ontology. The objective
is therefore to generalize and enlarge the coverage of the Software
Service Ontology. The generalization is achieved by applying the concept
from a software-service context to the general context of a service system,
which includes the physical and the manual system. The practical target
is to cover concepts included in the classic service engineering context but
missing in informatics service engineering, such as (1) ‘value’, (2)
‘business process’, (3) ‘business model’ and (4) ‘capability’. These four
concepts are the target components to be integrated with concepts
already covered within the Software Service Ontology.
3.4.1 Ontology Source Material
Inspired by the existence of ISO/IEC 18384:2016, the general ontology is
built based on the available standard documents published by the
64
International Organization for Standardization (ISO) and Object
Management Group (OMG). Sixteen standard documents were identified
to cover the definition of targeted concepts. The identified documents
originated from both business and technical domain, including IT domain.
The ISO/IEC 18384:2016 (SOA Reference Architecture) is re-used here for
to its general feature. Table 3.4 lists the source document for building the
consolidated ontology.
Table 3.4: Identified Standard Documents for Concepts Definition
Name Description Code
1 ISO 2382 Information Technology (IT) Vocabulary [ITV]
2 ISO 9000 Quality Management Systems [QMS]
3 ISO 14662 Open Electronic Data Interchange (EDI) [EDI]
4 ISO 15288 System Life Cycle [SYLC]
5 ISO 15944 Business Operational View [BOV]
6 ISO 16500 Digital Audio-Visual (AVI) System [DAVI]
7 ISO 12207 Software Life Cycle [SWLC]
8 ISO 18384 Service Oriented Architecture (SOA) Ref. Architecture [SOA]
9 ISO 19505 Unified Modeling Language (OMG’s UML) [UML]
10 ISO 19510 Business Process Model & Notation (OMG’S BPMN) [BPMN]
11 ISO 30102 Distributed Application Platforms and Services [DAPS]
12 ISO 90003 Software Engineering [SWE]
13 ISO 14813 Intelligent Transport System [ITS]
14 OMG - VDML Value Definition Modeling Language [VDML]
15 OMG - BMM Business Motivation Model [BMM]
16 OMG - SoaML Service Oriented Architecture Modeling Language [SoaML]
Some of the source documents contain a partial ontological view of
concepts covered in the document, i.e. ISO 18384 (SOA-RA), ISO 19505
(OMG-UML), ISO 19510 (OMG-BPMN) and OMG-BMM. In these cases,
the targeted concept definition is extracted, along with the available
defined relation between them. For other documents, only the concept
definitions were extracted. If available, the definitions were captured
65
from the formal terminology definition section. In other cases, implied
definition is extracted from the descriptive narration.
A total of 74 concept definitions are identified. These concepts are
arranged and grouped based on similarity (table 3.5 to table 3.21).
Concepts observed to be covering similar idea are later merged into a
representative label.
Table 3.5: Entity-related Concept Definitions
id Concept Description Source
1 Element Unit at a given level of abstraction and with a clearly defined boundary [SOA] [DAPS]
2 Participant An entity or a role that controls or is responsible for a business process. [BPMN]
3 Participant Anything that fill a role in collaboration, e.g. actors, collaborations or roles [VDML]
4 Participant A party or component that provides and/or consumes services [SOAML]
5 Actor An indivisible participant [VDML]
6 Actor Entity that fulfils a role [ITV] [ITS]
7 Actor Specification of an interactive role played by a user or other system [UML]
8 Actor A person or system component who interacts with the system as a whole and who provides stimulus which invoke action
[DAVI] [DAPS]
9 Actor Person or system component that interacts with the system as a whole and provides stimulus which invokes actions
[SOA]
10 Entity Anything that exists, did exist, or might exist, including associations of things [BOV] [ITV]
11 Entity System’s element in which can act as a service provider or consumer. [SOA]
12 Party Organization entering into an agreement [SYLC]
Table 3.6: Process-related Concept Definitions
id Concept Description Source
13 Business A series of information exchange processes, involving more than one person, directed towards mutually agreed goal, over a period of time
[EDI], [BOV]
14 Business process
A container of processing steps, sequences, structure, interactions, and connection to events that trigger the processes.
[BMM]
15 Business process
A defined set of activities as steps to achieve an objective, includes the flow and use of information and resources.
[BPMN]
16 Business process
A process that is designed to deliver outputs that satisfy business objectives. [QMS]
17 Process A set of interrelated or interacting activities that use resources to produce a result by transforming inputs into outputs.
[QMS] [SYLC]
18 Process Type of composition whose elements are composed into a sequence or flow of activities and interactions with the objective of carrying out certain work
[SOA] [DAPS]
19 Process A sequence or flow of activities in an organization with the objective of carrying out work
[BPMN] [VDML]
20 Process Series of actions or events taking place in a defined manner leading to the accomplishment of an expected result
[BOV]
66
Table 3.7: Activity (sub-process)-related Concept Definitions
id Concept Description Source
21 Sub-process
A compound activity that is included within a process or choreography can be broken down into a finer level of detail through a set of sub-activities.
[BPMN]
22 Activity A work performed in a process, atomic (sub-process) or non-atomic (task). [BPMN]
23 Activity A collection of related (cohesive) tasks of a process [SWLC] [SWE] [SYLC]
24 Activity Output producing work element required by a process, as tasks or operations. [QMS]
25 Activity Sequence and conditions for coordinating lower level behaviours. [UML]
Table 3.8: Task (atomic-activity-related Concept Definitions
id Concept Description Source
26 Task An atomic activity that is included within a process [BPMN]
27 Task Atomic action which accomplishes a defined result. [SOA]
28 Behaviour A respond specification of a classifier instance toward a request. [UML]
29 Action A fundamental unit of behaviour specification. [UML]
30 Action Activity to achieve something [QMS]
Table 3.9: Collaboration-related Concept Definitions
id Concept Description Source
31 Business Network
A collaboration between independent entities in an economic exchange. [VDML]
32 Business transaction
Predefined set of activities initiated to accomplish a shared goal and terminated upon agreed conclusions by all involved
[BOV] [EDI]
33 Transaction A sub-process that represents a set of coordinated activities of independent systems in accordance with a contractual relationship.
[BPMN]
34 Collaboration The act of sending messages between two participants in a process. [BPMN]
35 Collaboration Collection of participants joined together for a shared purpose or interest [VDML]
36 Collaboration A composition whose elements interact in a non-directed fashion, according to their own purposes without a predefined pattern of behaviour
[SOA] [DAPS]
Table 3.10: Choreography-related Concept Definitions
id Concept Description Source
37 Choreography A composition with a non-directed interaction following a predefined pattern of behaviour for the entire composition
[SOA] [DAPS]
38 Choreography Interaction scenario with roles rules and information bundles of that scenario, in a predefined pattern and non-directed fashion for the entire instantiation
[BOV] [DAPS]
39 Choreography An ordered sequence of business-to-business (B2B) message exchanges between participants.
[BPMN]
40 Protocol Set of message formats (semantic, syntactic, and symbolic rules) and the rules for message exchange between peer layer entities
[DAVI]
41 Protocol Set of rules that determines the behaviour of objects in achieving communication and exchanging messages
[ITV]
67
Table 3.11: Interaction-point -related Concept Definitions
id Concept Description Source
42 End point Extension point of an element as a service address [BPMN]
43 Endpoint Location at which information is received (or sent) to invoke an interaction [SOA]
44 End node Endpoint node at the end of only one branch [ITV]
45 Port Participant’s interaction point for a service provision or consummation. [SOAML]
46 Port Unit through which data can enter or leave a network [ITV]
47 Port An abstraction of destinations identity associated with particular applications [DAVI]
48 Reference point A set of interfaces between any two blocks through which information flows [DAVI]
49 Channel A connection conveying information between blocks or with the environment. [DAVI]
50 Channel Mechanism to execute a deliverable flow [VDML]
51 Channel A component of a communication system that connects the source with target [ITV]
Table 3.12: Interface -related Concept Definitions
id Concept Description Source
52 Interface A set of operations that are implemented by services. [BPMN]
53 Interface Shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical interconnections, signal exchanges
[SOA] [ITV]
54 Interface A point of demarcation between two blocks through which information flows [DAVI]
55 Interface A declaration of public features and obligations set to be fulfilled by another classifier.
[UML]
Table 3.13: Operation -related Concept Definitions
id Concept Description Source
56 Operation A definition of messages that are consumed and, optionally, produced when the operation is called.
[BPMN]
57 Operation A behavioural feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behaviour.
[UML]
Table 3.14: Operation -related Concept Definitions
id Concept Description Source
58 Information bundle
Formal description of the semantics of the recorded information to be exchanged by parties playing roles in a scenario
[BOV] [EDI]
59 Message The contents of a communication between two participants (as defined by a business role or a business entity)
[BPMN]
Table 3.15: Service-related Concept Definitions
id Concept Description Source
60 Service Logical representation of a set of ‘activities’ that has specified outcomes, self-contained, and is a “black box” to consumers of the service
[SOA]
61 Service Output of an organization with at least one activity necessarily performed between the organization and the customer.
[QMS]
62 Service A mechanism to enable access to one or more capabilities, accessible through an interface with constraints and policies as specified by the service description
[VDML]
63 Service Capability of a layer provided to the entities of the next higher layer [ITV]
64 Service A set of elementary streams offered to the user as a program. [DAVI]
68
Table 3.16: Capability-related Concept Definitions
id Concept Description Source
65 Capability Ability of an entity to realize something that will fulfil the requirements [QMS]
66 Capability Ability to perform a particular kind of work and deliver desired value [VDML]
67 Capability Ability to act and produce an outcome that achieves a result. [SOAML]
Table 3.17: Business Model-related Concept Definitions
id Concept Description Source
68 Business plan.
Provisions made to fulfil mission, and vision and applying values in terms of the strategy, objectives, measures, targets and enabling processes.
[QMS]
69 Business model
A description of value creation, delivery, and capturing to fulfil the motivations [VDML]
Table 3.18: Rule-related Concept Definitions
id Concept Description Source
70 Business rules
A structured, discrete, specific, and practicable guidance for business process in the form of obligation or necessity.
[BMM]
Table 3.19: Contract-related Concept Definitions
id Concept Description Source
71 Constraint Rule, explicitly stated, that prescribes, limits, governs or specifies a transaction [BOV]
72 Contract A binding agreement [QMS]
Table 3.20: Value-related Concept Definitions
id Concept Description Source
73 Value A measurable factor of benefit to a recipient, in association with a business item [VDML]
74 Value stream Flow of material and information service from customer to suppliers. [QMS]
Table 3.21: Role-related Concept Definitions
id Concept Description Source
75 Role An expected behaviour pattern associated with participation in a collaboration [VDML]
76 Role A defined set of activities assigned to an entity to performs a specific function [SOA]
77 Role External intended behaviour specification within an interaction scenario [BOV] [EDI]
78 Thematic role
A function of that an entity may perform during the execution of a script. [ITV]
Some of the captured definitions may seem a little specific or out-of-
context, but they provide peripheral definition which is necessary within
the goal of generalization.
69
3.4.2 Consolidated Ontology
Table 3.22 lists the merged concepts into a hierarchy of 17 concepts as the
components of the ontology.
Table 3.22: Hierarchy of 17 Merged Concept Definitions
Concept Definition
1. Entity Individual element in a system which can act as a service provider or consumer.
1a. Interaction point Location at which information is received (or sent) to invoke an interaction
2. Business model A description of value creation, delivery, and capturing to fulfil the motivations
3. Process A set of business activities as steps to achieve a business objective
3a. Activity A collection of related (cohesive) tasks of a process
3b. Task An atomic activity that is included within a process, accomplishes a defined result.
3c. Rule A structured, discrete, specific, and practicable guidance for business process
4. Service A set of a capability’s ‘activities ’accessible through an interface with constraints.
4a. Interface Shared boundary between two units, characterized by operations
4b. Operation A definition of messages consumed and, optionally, produced when called.
5. Capability Participant ability to act and produce an outcome
6. Value A measurable factor of benefit to a recipient, in association with a business item
7. Collaboration Predefined set of activities and/or processes initiated to accomplish an shared goal
7a. Role A defined set of activities assigned to an entity to performs a specific function
7b. Choreography An ordered sequence of message exchanges between two or more entity
7c. Contract Explicitly stated rule, that prescribes, limits, governs or specifies transaction
7d. Message The contents of a communication between two participants
Entity
Boundary Service
Interface
Operation
Message
Entity
Business
Model
Process
Rule
Collaboration
RoleChoreograpy
(Contract)
Capability Value
use
Part
of
sequence
useProcess
Task(Atomic)
Activity(Composite)
use
has exchange
exchange
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
use
1
2
3
4
5 6
7
3a
3b
3c
4b
4a
7b
7c
7d
govern
Data Asset use
has
Interaction
Point
Per-
form
has
7ause
1a
Figure 3.12: General Service Engineering Ontology
70
The ontological relations between each merged concept are
visualized in the figure 3.12. For ease of reference, the numbering in the
figure is correlated with the number in table 3.22.
As defined in the table, Service is a container for Interface and its
Operation. In the visualization, these service components are also
aggregated with the underlying process component, i.e. Activity and
Task, to form a larger abstraction of Service, between the front-end
interface and the back-end supporting activities. This also reflects a
SoaML perspective regarding the relation between ‘process’ and ‘service’
as different views of a similar object. ‘Process’ view focuses on the how
and why of the interaction, while ‘service’ focuses on participant activities
in provision and consumption of services [60].
A shaded container is introduced in the visualization to define the
‘Entity’ ownership boundary. Three components protrude beyond the
boundary: (1) Collaboration, as an abstraction of atomic or composite
interaction, (2) Choreography, where the arrangement of interaction
sequence is defined as a ‘contract’ agreement with an outside entity, and
(3) Message, which is exchanged with parties beyond the boundary.
A pair of concepts is merged in the ontology visual: Choreography
(7b) with Contract (7c). This merger is not only implemented for visual
simplification, but also to show the strong intersection between the two as
an interaction arrangement. To be precise, choreography refers to the
sequencing aspect, while contract refers to the rule and constraint.
71
3.4.3 Differentiating Software from General Context
As can be observed in the previous section, the produced general ontology
(figure 3.12)captures concepts from a software-service context (section
3.3) with concepts from classic service engineering, i.e. (1) ‘value’, (2)
‘business process’, (3) ‘business model’ and (4) ‘capability’. In practical
engineering level, different treatments are performed for each IT-context
and non-IT context. This section explores the abstraction separation
between a software-service and a non-software service.
The type of ‘service encounter’ is the differentiating factor between
software and non-software service. Two types of service encounters are
defined in [23]: (1) Physical, and (2) Virtual. If an interaction of an
encounter is mediated by technical devices, the encounter is categorized
as a virtual encounter. In this typology, technology may facilitate the
encounter in various forms, e.g. from e-mail to website. The software-
services context resides in a specific situation, in which a software
component offers service consumables by other software components
(example 5 and 7 in table 3.23).
Table 3.23: Typology of the Service Encounter with examples[23]
Type of Encounter
Direct (end-customer facing)
Indirect (external interface usage)
Physical (1) Service Counter (Consumer Visit) (2) Provider visitation
(3) B2B service flow through shared physical collaboration space
Virtual (4) Email, chat, phone, video-conferencing (5) Software service (consumable by consumer-side client application/browser)
(6) B2B virtual collaboration space (email, chat, phone, video-conferencing, document flow) (7) Software Service (electronic B2B interaction)
72
Service
Customer
Service
Representative
Technology
A. Technology-Free
Service
Customer
Service
Representative
Technology
B. Technology-Assisted
Service
Customer
Service
Representative
Technology
B. Technology-Facilitated
Service
Customer
Service
Representative
Technology
B. Technology-Mediated
Service
Customer
Service
Representative
Technology
B. Technology-Generated
(Self-Service)
Figure 3.13: Typology of Customer Contact [4]
In a more detailed fashion, figure 3.13 illustrates five archetypes of
customer contact in relation to technology is defined [3][4]:
1. Technology-free, a face-to-face service encounter without direct
technology involvement in service provision
2. Technology-assisted, face-to-face encounter is facilitated by
technology without consumer involvement in technology access.
3. Technology-facilitated, a face-to-face encounter where both
provider and consumer access the same technology.
4. Technology-mediated, provider and consumer are not physically
connected and technology is employed to enable communication.
5. Technology-generated, provider is represented by a
technological component to form a degree of a self-service
encounter.
73
While software-services may exist to facilitate the last four
archetypes (2 to 5), the software-service context is mostly apparent in the
last two (4 and 5), technology mediated, and technology generated, where
no physical encounter is established between the provider and consumer.
In these two types of encounter, the interaction is performed over a
network, e.g. Internet, facilitated by software components, e.g. websites,
and software-service.
3.4.4 Consolidated Software Ontology
As intended, the produced General Service Engineering Ontology (figure
3.12) covers the additionally targeted business concept. To refocus on the
software context, the ontology is trimmed to only include software related
concepts. By excluding the three business analysis level components, i.e.
(1) values, (2) capability, and (3) business model, the 17 components in
the general context are reduced to 14 components for software-service
context, as listed in table 3.24.
To achieve a uniformity and as a form of triangulation, SoaML
ontology is also juxtaposed (in table 3.24) and adapted with the structure
of the consolidated software-service ontology into the resulting ontology
as presented in figure 3.14.
74
Table 3.24: Concepts for Software Service Context
General Context
(table 3.22)
Software-service context
SoaML label (table 3.2)
1. Entity 1. Software component 1. Participant
1a. Interaction point 1a. Port 2. Port
3. Process 3. Software service* -
3a. Activity 3a. Composite service 3. Service Interface
3b. Task 3b. Atomic service 4. (UML) Interface
3c. Rule 3c. Service contract** 5. Service Contract†
4. Service 4. Software service* -
4a. Interface 4a. Service interface 3. (UML) Interface 4. Service Interface
4b. Operation 4b. Service operation 9. Operation
7. Collaboration 7. Software interaction 9. Interaction Protocol‡
7a. Role 7a. Component role 7. Role
7b. Choreography 7b. Interaction Protocol 9. Interaction Protocol‡
7c. Contract 7c. Service contract** 5. Service Contract†
7d. Message 7d. Message 10. Message type
Merged concepts are marked with pairs of *, **, † and ‡ symbols
IT Ownership Boundary
Service
Interface<Interface>
Operation
Message
Software
Component<Entity>
Service
Contract<Rule>
Software
Interaction<Collaboration>
Role
has
Software
Service <Service>
Atomic
Service
Composite
Service
exchange
has
Perform
1
Port<Interaction Point>
1a
has
has
has
use
refer
use
3
3a
3b
3c
7
7a
7d
4a
4b use
7c
4
sequencing
Part
of
use
use
Interaction
Protocol<Choreography>
7b
Figure 3.14: Consolidated Software Service Ontology
In this software service context, the term ‘service’ represents an
abstraction of externally accessible software components. It therefore
75
covers both the underlying software component behaviour (3a and 3b)
originated from the ‘process’ context, and the related published
description (4a and 4b). Similarly, the term ‘service contract’ merges the
two aspects of: internal process rule (3c), with the externally shared and
agreed rule (7c).
These characteristics are derived from SoaML’s feature in
superimposing a service component with its description. This merging is
also coherent with SoaML perspective that treats ‘process’ and ‘services’
as different views of the same object [60].
Two additional SoaML components are not represented in this
context: (1) Capability, and (2) Service Architecture. The two is decidedly
to reside in the business analysis level of service engineering.
Components decoupling and its binding mechanism is an important
principal in SOA conception [24]. It is also the underlying motive in
introducing SoaML over UML limitation [63]. As an exercise, these
concepts are narrated in the context of the produced software service
ontology diagram in figure 3.14.
A service decoupling is implemented as a separation between a
published service description (component 4a and 4b) and its underlying
supporting behaviours (component 3a and 3b). Service behaviours
(component 3) are actually a part of a specific software component
(component 1).
Binding, or more precisely role-binding, is an execution time
instance when a software component (component 1) assumes a role
76
(component 7a) within a context of specific software interaction
(component 7), using the service interface (component 4a) as the guidance
in invoking its internal behaviours (component 3a and 3b), via its defined
port (component 1a) as the location address, for message (component 7d)
passing operations (component 4b).
The ontology visualization structure is not only describing a service
providing software component. In a case where a component requires
services from other component within its own composite behaviour
(component 3a), it follows the previously described role binding
mechanism. The difference is that the software component (component 1)
assumes ‘consumer’ role (component 7a) and adheres to a collaboration
mechanism (component 7), which is implemented by service (component
3a and 3b) from the providing software component.
These conceptual exercises for decoupling, binding and service
consumption demonstrate the capability of the ontology in covering the
basic SOA concepts for the context of software service engineering.
3.5 Patterns of Service System
As an attempt to assess the feasibility of the ontology, various patterns of
a service system are applied to the ontology. The patterns of service
system are implied and analogous with the three abstraction level of
service modelling: (1) single interaction, (2) choreography, and (3)
orchestration [16]. These exercises can be seen as a proto-
77
operationalization of the metamodel ontology toward domain ontology
(figure 3.1)
Consumer
Boundary
Provider
Boundary Service
Interface
Operation
Message
Provider<Entity>
Business
Model
Process
Rule
Transaction<Collaboration>
Provider<Role>
Choreograpy<Contract/Protocol>
Capability(Offered)
Value(Proposed)
use
Use
has
sequence
hasProcess
Task(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
govern
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
Part of
Consumer<Entity-Role>
Value(Proposed)
Activity<Operation-Task>
exchange
sequence
Use
perform
has
exchange
use
Interaction
Point
Figure 3.15: Model of a Simple Service System
Figure 3.15 visualizes the first pattern for a simple interaction
between a service provider entity and a service user, e.g. individual end-
user consumer. Here, the whole ontology set is positioned as the service-
providing entity. To illustrate the first pattern of interaction, the ontology
is paired with a simple consumer outside the entity boundary.
Among others, the resulting models covers the concepts of: (1)
capability offered by the service provider, (2) value offered and requested
by the consumer, (3) value brought by the consumer (e.g. in the form of
monetary asset), (4) choreographed activity between the two entities, and
value exchanged during the transaction.
In the second pattern, choreography level of abstraction, a service is
modelled as a complex process with multiple interactions between two
78
entities. A business-to-business (B2B) arrangement between a company
and its supplier is an example of this pattern. Figure 3.16 illustrates this
pattern by pairing two ontology sets as two interacting entities.
Figure 3.16: Model of a B2B service pattern
The resulting model visualizes pairs of external behaviour requested
and offered by each participant in the pattern. This pattern specifies and
analyses interoperability between two service participants. The model
structure also introduces the concept of ‘collaboration space’ in which the
interactions take place. It may reside (i.e. owned) within one of the
participant boundary, or in independent third-party location. In the
software-service context, the ‘collaboration space’ relates to the operator
and controller of software-service repository, i.e. service registry and
service publication.
Entity B
Boundary
Entity A
Boundary Service
Interface
Operation
Message
Entity A
Business
Model
Process
Rule
Collaboration
Role
Choreograpy<Contract/Protocol>
Capability Value
use
has
sequence
hasProcess
Task(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
govern
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
Part of
use
Service
Interface
Operation
Entity B
Business
Model
Process
Rule
Role
CapabilityValue
use
sequence
has Process
Task(Atomic)
Activity(Composite)
use
hasexchange
exchange
perform
govern
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
Part of
use
Collaboration
Space
Interaction
Point
use
Interaction
Point
use
79
Figure 3.17: Model of a multi-provider service pattern
In the third pattern, orchestration abstraction, an offered service is
modelled as a composition of other services. Figure 3.17 illustrates this
pattern by combining the first and second pattern approaches with the
introduction of both a simple customer, and a partnering service co-
provider.
This pattern is related with indirect type of service encounter in the
typology of service encounter [23], where an external party is involved in
the service process, as co-provider or intermediary, and may make a
direct contact to the service-consumer. In a more complex pattern,
multiple co-providers may forms service architecture over a set of
services. Consequently, this model can be used to analyse and specify
possible implementation of the offered service.
Entity B
Boundary
Entity A
Boundary Service
Interface(Interaction Point)
Operation
Message
Entity A
Business
Model
Process
Rule
Provider A(Role)
Choreograpy(Contract/Protocol)
Capability Value
use
has
sequence
hasProcess
Task(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
has
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
Part of
use
Service
Interface(Interaction Point)
Operation
Entity B
Business
Model
Process
Rule
Provider B(Entity)
CapabilityValue
use
sequence
has Process
Task(Atomic)
Activity(Composite)
use
hasexchange
exchange
perform
has
has
Motivation(Vision, Mision,
Strategy, Goal)
has
drive
has
refer
Part of
use
Consumer(Entity-Role)
Value(Proposed)
Activity(Operation-Task)
exchange
Use
has perform
Use Use
Sequence
Transaction(Collaboration)
exchange
Interaction
Point
use
Interaction
Point
use
80
The model also raises the issue of ‘collaboration spaces’. It relates to
the existence of a service coordinator, with the central role of interacting
and orchestrating other providers. While the arrangement can be made to
be in equal term (distributed and federated), each particular of
collaboration tends to require a dominant participant role as the main
operator.
Other types of service system patterns and combinations may exist,
related to elaboration of provider role and components of collaboration
space, but the three illustrated patterns adequately demonstrate the
feasibility and flexibility of the produced ontology in covering various
types of service system.
In summary, this chapter has demonstrated the process of
foundational ontology building in the context of ‘service engineering’. The
produced ontologies are an integral part of the preliminary framework to
be discussed in the next chapter, in defining the context, scope, and
terminologies definition within the framework. As a form of verification
in the fifth chapter, a concept mapping is performed between the
ontologies, from this chapter, and the framework of the next chapter.
81
Chapter 4
Service Engineering Framework
4.1 Introduction
This chapter address the second and third research question, i.e. the
‘activity’ and ‘artefact’ of a service engineering, in the form of service
engineering. Several iterations of the framework were produced
throughout this research scope. Figure 4.1 describes the content of this
chapter in terms of the flow of the research.
Related Service
Engineering Work
Identify Service
Engineering
Core Concepts
Service
Engineering
Framework(1st iteration)
Figure 4.3
Literature
Review
Case Study
(First Round)
Service
Engineering
Framework(2nd iteration)
Figure 4.18
Case Study
(Second Round)
Service
Engineering
Framework(3rd iteration)
Figure 4.23
SoaML
Exploration
Software Service
Ontology
Table 3.24
Figure 3.14
Sec 4.3
Sec 4.2
Sec 4.4
Sec 2.2
Sec 3.3.1
Literature
Review
SOA
Literatures
Classic Service
Engineering
Service
Engineering
Framework(1st iteration)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
Software Service
Ontology
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework(3rd iteration)
Literature Review
Framework (RQ2, RQ3, RQ4) Ontology (RQ1)
Modeling (RQ4)
Ch 4
Ch 2
Ch 3
Ch 5
IntroductionCh 1
ConclusionCh 6
Case Study
(Second Round)
Service
Engineering
Framework(Generalized)
Activity’s
NarrationArtifact
Legend:Section
Number
Sec # Figure #.#
Artifact
Number
Sec 4.1
Figure 4.1: Research Flow and Content Map (Chapter 4)
82
An engineering process can be viewed as a transformative activity
bridging an analysis perspective into an architectural perspective, in
which functional and behavioural views are adapted into structural views
of functional components. In the case of software engineering, the initial
definition UML’s use cases are to be implemented as (software) objects
with certain hierarchy and dependencies [81].
A similar principal is also applicable in the service engineering
context, where business directives and process flow definitions are to be
implemented as an architecture of service components. In this regard,
service engineering tends to have a greater scope than a regular software
engineering, where the business side is not always a given parameter but
rather a modifiable context to be re-assessed and re-designed during the
process [66].
Market
Engineering
Environtment
Market
Platform
Ontology
Engineering
Domain
Ontologies
Market
Strategy
Mechanisms
Organization
Strategy
Collaborative
Process
Local
Process
Process
Engineering
Service
EngineeringService
drive
utilize
construct
construct
specify
utilize
specify
Derived
from
Annotated
by
construct
construct
drive
use
useutilizeAnnotated by
Projected to
‘Business Side Engineering’
Figure 4.2: Integrated Methodology for Service-Oriented System[82]
This perspective is shared in service engineering literature
[10][35][31][32][13]. For example, in a bigger context of a service-oriented
system, service engineering is associated with process engineering,
market engineering and ontology engineering as illustrated in figure
83
4.2[82]. Consequently, business and process analysis are often performed
within service engineering activities.
The service engineering framework targeted in this research is
emphasized in the IT context, therefore limiting its concern in business
side analysis and manual services. An abstraction for business and
process analysis is provided but their elaboration is considered to be out
of scope for this research context.
An important abstraction representing business side analysis and
design in service engineering is the concept of the ‘business model’, as an
intermediary layer between the ‘strategic layer’ and ‘process layer’[83].
The development of a new service, i.e. service engineering, is essentially a
design process of anew or improved business model [84]. In fact, a
business model can be considered as the key artefact to produce during
business side analysis, as an input for the subsequence service design
stage[27][75].
The business side analysis is commonly initiated with activities
relating to business idea generation and assessment[27], in parallel with
business Strengths, Weaknesses, Opportunities, and Threats (SWOT)
analysis[7]. The selected business concept is then elaborated into a
business case description which covers the reasoning from market
analysis, customer requirement analysis, and financial reflection, which
are integrated into a business model.
As a dominant format in business modelling, Business Model
Canvas (BMC) [85] is an ubiquitous format for representing a business
84
case. BMC covers all core aspects of a business model within a simple
visualization. Therefore, the format facilitates a holistic view and allows
an easy comparison between different business models [84].
The actual service design stage should follow the business-side
analysis and design activity [11][75]. In this stage, the service concept is
elaborated by detailing the defined business model. Aspects covered in
this stage are: service description, service processes, service resources
(employees, facilities), customer benefit (tangible and intangible), and
customer engagement from a marketing aspect [27].
Two fundamental aspects of service design activity are (1) the
process model and (2) customer engagement[86][87]. The process model
identifies and describes all the activities required to fulfil a service, while
the customer engagement concept elaborates the manner of interaction
between the service consumer and the providing participants.
These two aspects are actually overlapping in describing a service
process. The difference is that the second aspect, customer engagement, is
a higher abstraction of the process with the focus only on the detail of the
interaction, while the process model elaborates all the activity involved in
a service.
The classic service engineering literatures tends to focus only on the
second aspect, while the informatics service engineering emphasizes on
the first aspect. A specific focus on the series of interactions is beneficial
for a detailed analysis from a consumer perspective, e.g. interaction mode
85
and facilitation, which is often neglected in the overall process model
description.
In the context of a service process, the Service Blueprinting [88]
format is often suggested in classic service engineering literature
[89][6][13]. On the other hand, the artefacts for process model commonly
use the dominant BPMN metamodel format [90][91][40][92]. By
combining both the interaction and process aspects, a comprehensive
analysis can be expected which equally covers all perspective of an
involved participant.
Following the service design stage, the subsequent stage further
elaborates the service design for the use in the implementation stage. In
case of identified potential use of software interactivities, the design
activity is shifted into the IT perspective in designing software-services.
The process is a special case of software-engineering with service-
orientation analysis as prescribed in various SOA methodologies (SOM).
During this stage the design artefacts adopt the format of software-
engineering modelling, e.g., UML or SoaML.
To summarize, the analysis and design activities in service
engineering can be divided into two stages: (1) Pre-Service Design, and (2)
Service Design. The pre-service design covers business side analysis with
an end result of a business model. The service design stage produces the
description of service model in two aspects interaction model and process
model. For the special case of software interactivity, the service design
86
stage is continued to the software-service design sub-stage, which is
performed in a manner of software engineering analysis and design.
4.2 Preliminary Framework
Two research streams are identified in the context of Service
Engineering. The first stream takes the more classical perspectives of
service by emphasizing on ‘business-service’ context [26][31][32]. The
second stream enlarges the context, but puts more emphasize on the
‘software-service’ context [13][67][53]. The second stream pursues an
enterprise-wide alignment of business-services with the architecture of a
‘software-service’, often by adopting various Service Oriented
Architecture Methodologies (SOM), such as MSOAM [24] or SOMA [47].
Combining these streams, a SvE framework prototype is proposed.
The framework is composed based on the SAT (Stage-Activity-Technique)
framework structure [31]. ‘Stage’ is a high-level concept in partitioning
the process in steps. A stage is a container for one or more ‘activities’, and
‘technique’ is a tangible instrumental aid for performing an activity, e.g.
Focus group, Delphi, SWOT analysis [13].
In generalizing the structure, and to reduce the prescriptive detail of
the framework, the ‘Technique’ component is replaced with an ‘Artefact’
component. Artefact is defined as an output for an activity and may serve
as an input for the subsequent activities. Certain techniques may be
involved in producing the artefact, but this detailed ‘how’ aspect is
87
omitted to retain the abstract level of the targeted framework and to
allow development flexibility.
Instead of adopting the ‘technique’ component, specific format is
specified for each type of artefact as suggested by literature, i.e. the
Business Model Canvas (BMC) [85], Service Blueprint (SBP) [88], and
Business Process Model and Notation (BPMN) [93].For software
modelling, UML is proposed as the most common notation for software
analysis and design. These formats imply that the technique of each
activity should use and produce the formatted artefact during the process
of analysis and design. This approach ensures the open-ended nature of
the proposed framework. Table 4.1 summarizes these components into a
prototype of the service engineering framework.
Table 4.1: Service Engineering Framework (prototype)
Stage Activity Artefact Format
1. Identification Requirement gathering Business modelling
Existing business model Business requirement Proposed business model Business service catalogue
BMC (as-is) Structured narratives BMC (to-be) Structured table
2. Design Service Modelling Process Modelling Software Modelling
Service model Process model Software model Software Service Catalogue
Service Blueprint BPMN UML Structured table
As an initial refinement of the prototype, the activities in case
studies are grouped into four activities: (1) Understanding the service
context, (2) defining the service concept, (3) designing the business
service, and (4) designing the software services. Each activity is
88
operationalized with output artefacts and its suggested format. This
structure is summarized and illustrated in figure 4.3.
1.2.1
Business
Model
2.1.1
Interaction
Model
2.1.2
Process
Model
2.2.1
Software Service
Model
2.1 Business-Service
Design2.2 Software-Service
Design (SOM)
1.1.1
Requirement
List
1. IDENTIFICATION 2. DESIGN
1.1 Understanding
Service Context
1.2 Defining
Service Concept
1.2.2
Business
Service
Model
Business
Model
Canvas
(BMC)
Business
Service
Catalogue
Service
Blueprint
(SBP)
Business
Process
Modeling
Notation
(BPMN)UML
diagrams
Software
Service
CatalogueSurvey and
Observation
Results
Stage
Activity
Tool
(Format)
Artefact
Figure 4.3: Service Engineering Framework (1st iteration)
The identification stage is the first stage as a business side analysis
in which potentials for new services are identified and proposed with
analysis of existing condition of the organization. The design stage, as the
second stage, consists of both the business design and technical design
processes. The services are designed or redesigned in this stage with
regard to the existing condition of the organization.
This initial framework is considered to be sufficiently covering five
core aspects of service engineering identified in the previous section: (1)
Business Model, (2) Service Model, (3) Interaction Model, (4) Process
Model, and (5) Software Model.
4.2.1 Identification Stage
In the identification stage, potential new business service for a customer
is identified and defined. A common motive of anew service innovation is
89
to improve customer value. In that sense, the service identification stage
must consist of steps to identify services with high customer value.
A common identification technique for service innovation is the
questionnaire method. The technique is commonly used during a market
research activity. The use of questionnaire is part of true requirement
investigation, as the requirement is defined based on actual interaction
with prospective customers [13]. An analysis from the questionnaire data
might instigate a new service innovation. For example, the questionnaire
result might suggest an improvement in the firm key activities.
Therefore, a service innovation can be introduced in the back-end to
enhance the actual service activities.
Another common technique of true requirement investigation is the
observation. Observation is a method to capture the information based on
a real-world situation. The observation process can also include a
questionnaire, or interview activities. During the observation, the
researcher directly visits or experiences the site of the actual business
process and customer transactions performed.
New service innovations are frequently driven by implementing new
IT components. An assessment for IT potential is therefore valuable in
the identification stage. The latest trend in IT, such as cloud computing
offering, could serve as an important element in the service innovation.
The Business Model Canvas (BMC) [85] format is proposed in this
stage as the artefact format and also as the analysis and modelling tool to
identify potential components to improve in defining a service. The nine
90
blocks of the BMC are the analytical bases for improving the firm value
(figure 4.4). The potential of improvement might arise from the customer
segment, revenue stream, cost structure, value proposition, or in key
activities.
Cost Structure Revenue Streams
Key
Activities
Key
Resources
Key
partners
Value
Propositions
Customer
Relationship
Channels
Customer
Segments
Process
Model
Resource
Model
Product
Model
Marketing
Plan
Mini
Business
Plan
Figure 4.4: BMC context in Service Engineering[84]
The identification stage might also be assisted by the definition "as-
is BMC", to be analysed into the proposed "to-be BMC". This new BMC
represents the proposition of service innovation. For example, the
improvement decision might reside in the value proposition block. In this
case a new service is proposed for the customers, in the form of direct
customers facing services.
The “to-be BMC” serves as the starting point in service design. Each
component of BMC eventually forms components of service design:
Resource model, Process Model, Product Model and Marketing Plan. The
"to-be BMC" is complemented with a summary list of the service
innovation idea. Both components should be formalized as part of a
business service identification document.
91
4.2.2 Design Stage
The design stage of the proposed framework is divided into two sub stages
(activity): Business-service design, and software-service design. The goal
of the first activity, the business-service design, is to create the design of
the service defined from analysis in the identification stage. The second
activity, software-service design, is the sub-stage to elaborate the design
of software component structure using SOA approach and methodology.
During service process design, the service blueprinting (SBP) format
(figure 4.5) [88] is suggested to visualise a series of service interactions
between the service provider and consumer within the whole cycle of the
business service. The format defines five layers for service interaction:
physical evidence, customer action, on-stage contact employee, back-stage
contact employee, and support process.
Physical Evidence
Customer Action
Line of Interaction
Onstage Contact
Employee Action
Line of Visibility
Backstage Contact
Employee Action
Line of Internal Interaction
Support Processes
Figure 4.5: Service Blueprinting Template
The actual focus for the interaction model is only in the two top most
layers. The detailed process beyond the line-of-visibility is provided in the
92
process model. Business Process Model and Notation (BPMN) is used to
elaborate the supporting process in the context of service provision. As
required, a more detailed process abstraction can be further elaborated to
produce the most atomic abstraction of activities.
The objective of the business service design sub-stage is to have an
overview of the service. The result from this process will be used as a
reference to identify the role of the software service during the
interaction, and during the execution of the supporting process. Some
automated feasibilities in interactivity and operation serve as the basis
for devising software-services in the subsequent activity of software-
service design.
In the software-service design activity, a SOA methodology guides
the creation of services in an IT context, i.e. software service. A SOA
methodology commonly involves an identification activity followed by a
design activity. The purpose of identification is to identify the candidate
services, while the purpose of the design stage is to define the services
specification, such as the service contract and choreography.
In the proposed framework, some parts of SOA service identification
have already been performed during the previous stage, in the form of to-
be BMC, service blueprint and BPMN. These artefacts are the starting
point for Service identification for SOA methodology.
In the case of adopting Thomas Erl’s MSOAM [24], the first step of
the methodology, ‘Business Model Alignment’ , is simplified by employing
the results of BMC analysis. The same idea is also applicable to ‘Business
93
Requirement Definition’ and ‘Decompose Business Process’, in which the
Interaction Model and Process Model artefacts can be used.
A clear delineation should be made regarding the ‘Software-Service
Design’ (activity 2.2). While SOM generally does not limit the analysis on
the software-service alone, it will only elaborate a subset of operation
interactivity with feasible software enablement. Therefore, manual
services are defined only until the ‘Business Service Design’ (activity 2.1)
to be further elaborated in anon-IT manner, while the software-services
are elaborated through the ‘Software-Service Design’.
4.3 Case Studies
To assess the feasibility and its sufficiency, the first version of the
framework was applied in three separate service projects asresearch case
studies.
4.3.1 Case Study 1 – Citizen Registry
The first case study is focussed on improving the performance of business
services in a local governments’ citizen registration office. The project
scope covers the aspects from customer facing business-services through
to its implementation as software-services.
For understanding the service context, the case study conforms to
the framework by initiating a qualitative approach to the requirement
94
process. In this process, a list of high-level directives, problems, and
opportunity were compiled (table 4.2). The directives are collected from
documented narratives defining the services mandate. The high-level
problems are defined from business process analysis which measures a
performance gap between the current service situations and mandated
service performance. Service performance is measured from both the
conformance to transparency principles and service time. The
opportunities list is drawn from the directives and identified problem as a
list of high-level items for improving the performance of business service.
Table 4.2: Key Performance Indicator Analysis (Case Study 1)
This first stage produced a proposed service innovation, formalized
in the format of BMC. The produced BMC highlights the innovation in
three of its component: (1) Activity, (2) Value, and (3) Channel. The
service innovation is also accompanied with a catalogue of targeted
business-service, along with the improvement criteria.
KPI Rethink Redesign Retool
vision and mission of the Strategic plan and
working plan based on Law No. 25 of 2009
Motto service capable of motivating
employees
Motto Announcement Service
The preparation , establishment and
implementation of service standards based on
Law No. 25 of 2009
Notices Publication Services
Certificate of ISO 9001 : 2008 is based on
Law No. 25 of 2009
Implementing a Quality Management System
(QMS), and do not have the certificate of
ISO 9001 : 2008
Determination of Standard Operating
Procedures (SOP)
Determination clear of Duties
Guidelines for determining and applying of
ethic employee code
Employee Attitude and Behavior in providing
services
Employee discipline level in providing services
The response rate of employees in providing
services
The skill level of employees in providing
services
Determination of employee development
policies in order to improve the skills of
employees
the use of optimal facilities and infrastructure
Comfort of facilities and infrastructures
services
Facilities of complaints
Complaints management procedures
Officers/Special unit for a complaint
management
Percentage number of complaints can be
resolved
Complaints management refers to the Minister
PAN - RB No. 13 of 2009 in order to
improve the quality of service
Implementation of the IKM Survey
IKM Survey conducted refers Kepmenpan
25, 2004
The average scores obtained of IKM
Follow-up of the IM survey
Electronic information system services
Delivery of information public services to the
citizen
Disclosure of public service information
Establishing performance target of service
Achievement level performance target
A Rethink of the target and
the achievement of the
organization's performance
Routine evaluation of
performance in accordance
with the achievement of the
set target
Rethink of the achievements
and the recommendations of
the citizen satisfaction index
survey.
Business process redesign
propose for all kinds of
services
Evaluation of citizen
satisfaction survey on a
regular basis to determine
the level and
recommendations that
should be followed up.
A Rethink of the functions of
the Public Service and
public sevicecInformation
System disclosure issue
Redesign the public service
information system in order
to convey information to the
public as well as the
disclosure of directyly
information services to the
public
Rethink of the provision and
use of facilities and
infrastructure services
Routine evaluation of
facilities and infrastructure to
optimize the use and
enhance the user experience
of service
Rethink of complaints
management issues pursuant
to Rule Minister PAN - RB
13 2009
Redesign complaint
management through
information systems
Routine evaluation of
complaints and settlement
issues
Rethink to obtain
certification of ISO 9001 :
2008 and implement QMS
in administering public
services
Redesign of Standard
Operating Procedures
(SOP) for all types of
services provided
SOP Routine evaluation to
all kinds of services in order
to improve the quality of
service performance
Rethink of employee
performance
Routine evaluation of
employee performance in
accordance with applicable
regulations
Rethink of the planning
organization in setting goals
to be achieved and refer to
the Constitution No. 25 of
2009
Rethink of concerning the
establishment of service
standards based on Law
No.25 of 2009 and the
preparation and publication
of the notice services
KPI Rethink Redesign Retool
vision and mission of the Strategic plan and
working plan based on Law No. 25 of 2009
Motto service capable of motivating
employees
Motto Announcement Service
The preparation , establishment and
implementation of service standards based on
Law No. 25 of 2009
Notices Publication Services
Certificate of ISO 9001 : 2008 is based on
Law No. 25 of 2009
Implementing a Quality Management System
(QMS), and do not have the certificate of
ISO 9001 : 2008
Determination of Standard Operating
Procedures (SOP)
Determination clear of Duties
Guidelines for determining and applying of
ethic employee code
Employee Attitude and Behavior in providing
services
Employee discipline level in providing services
The response rate of employees in providing
services
The skill level of employees in providing
services
Determination of employee development
policies in order to improve the skills of
employees
the use of optimal facilities and infrastructure
Comfort of facilities and infrastructures
services
Facilities of complaints
Complaints management procedures
Officers/Special unit for a complaint
management
Percentage number of complaints can be
resolved
Complaints management refers to the Minister
PAN - RB No. 13 of 2009 in order to
improve the quality of service
Implementation of the IKM Survey
IKM Survey conducted refers Kepmenpan
25, 2004
The average scores obtained of IKM
Follow-up of the IM survey
Electronic information system services
Delivery of information public services to the
citizen
Disclosure of public service information
Establishing performance target of service
Achievement level performance target
A Rethink of the target and
the achievement of the
organization's performance
Routine evaluation of
performance in accordance
with the achievement of the
set target
Rethink of the achievements
and the recommendations of
the citizen satisfaction index
survey.
Business process redesign
propose for all kinds of
services
Evaluation of citizen
satisfaction survey on a
regular basis to determine
the level and
recommendations that
should be followed up.
A Rethink of the functions of
the Public Service and
public sevicecInformation
System disclosure issue
Redesign the public service
information system in order
to convey information to the
public as well as the
disclosure of directyly
information services to the
public
Rethink of the provision and
use of facilities and
infrastructure services
Routine evaluation of
facilities and infrastructure to
optimize the use and
enhance the user experience
of service
Rethink of complaints
management issues pursuant
to Rule Minister PAN - RB
13 2009
Redesign complaint
management through
information systems
Routine evaluation of
complaints and settlement
issues
Rethink to obtain
certification of ISO 9001 :
2008 and implement QMS
in administering public
services
Redesign of Standard
Operating Procedures
(SOP) for all types of
services provided
SOP Routine evaluation to
all kinds of services in order
to improve the quality of
service performance
Rethink of employee
performance
Routine evaluation of
employee performance in
accordance with applicable
regulations
Rethink of the planning
organization in setting goals
to be achieved and refer to
the Constitution No. 25 of
2009
Rethink of concerning the
establishment of service
standards based on Law
No.25 of 2009 and the
preparation and publication
of the notice services
95
As a direct customer facing service, the design stage is initiated with
a definition of customer interaction model. The interaction model is
formalized with Service Blueprinting diagram to illustrate customer
touch points with the registration office. The back-end processing is the
elaborated in BPMN notation (figure 4.6), in conformance with the
interaction model,
Figure 4.6: BPMN of the ‘to-be’ business process (Case Study 1)
For the software service design activity, the case study partially
adopted SOMA [47] as its SOA methodology. In producing the software
service candidates, two approaches were combined. The first approach
composed a Goal Service Model matrix which derives service candidates
from mandated goals and criteria. The second approach decomposed
business process into candidate operations and services. The two results
are consolidated and analysed to produce the (software) service catalogue.
96
Mobile App
RegistrationCreate
Application
Application
ProcessComplaint View Status Report
Application
Management
Online Application
Business Process
Services
Create Account
Data validation
Cek ID
Get InfoSubmit
Application
Upload forms
Get Appl. Ticket
Form Verification
Data Validation
SubmitMessage
Create Message
Update Status
Verifikation
Legalization
Get Record Tiket
Check Message
Update Message
Close Application
Update Application
GetStatus
Check Appl.Report
Get Appl.Report
Get Complaint
Report
Check Complain
Report
ApplicationManajement
Report ManagementServices
Components
Registration Account ApplicationApplication
StatusApplication
RecordCategory
Account Management
Operational Systems
Database SIAKDatabase SIAK Database Sistem KecamatanDatabase Sistem Kecamatan
Consumers/Citizen
Service Co
nsu
mer
Service Pro
vider
Website
Figure 4.7: Integrated Service Architecture (Case Study 1)
Figure 4.8: Adapted Service Engineering Framework (Case Study 1)
Entering the software design, the candidate services were
functionally grouped as service components. The usage structure of the
software services was also formalized in a use case diagram and use case
scenario. Afterward, the supporting data structure was composed as class
diagrams. Finally, as exemplified by SOMA, all the components were
combined into SOA Architecture (Figure 4.7), in a layered manner, from
Business
Modeling
Interaction
Modeling
Process
Modeling
Software-Service
Modeling
Business Service
DesignSoftware Service System Design
Requirement
Gathering
IDENTIFICATION DESIGN
Understanding
Service Context
Defining
Service Concept
Business
Service
Modeling
BMC(activity, value
channel)
Business
Service
Catalogue(features)
Service
Blueprint
(SBP)
To-be
BPMN Goal Service
Model
Software
Service
Catalogue
Problems,
Directives,
Opportunities
As-is
BPMN
Business
Process
Analysis
Decomposed
Process
Software System
Modeling
UML
Use Case
UML
Class Diagr.
SOA
Reference
Architecture
97
the business service to physical data assets. Figure 4.8 summarizes the
framework adoption in this case study.
4.3.2 Case Study 2 – Citizen Relationship Management
The second case study targeted a Citizen Relationship Management
system in a local government. The project emphasizes the aspects of
service goal and service value under the transparency mandate related to
an ‘Open Government’ initiative. As in the first case study, the service
under study contains a direct customer interaction in the form of a citizen
report, complaint or query.
Similar to the first case study, the project commenced in a
qualitative manner of requirement engineering by compiling a high-level
list of directive, problem and opportunity to understand the service
context and current situation. Afterward, a SWOT analysis is performed
to organize the qualitative results into feasible opportunities of service
innovations.
The intended service innovation was first formulated in a BMC
format. The improvement potential was identified in the components of
(1) value, (2) customer relationship, and (3) channel. The proposed service
innovation is composed into a business-service catalogue with a list of
mandated service features. The catalogue and features were formatted
into a matrix of the SOMA Goal Service Model to produce a list of
business sub-services.
98
In the interaction design, both the existing and future interaction
patterns are modelled using the Service Blueprinting format. The future
interaction pattern was designed to adopt the features mandated from
the identification stage. Detailed business processes were elaborated
using BPMN (figure 4.9). Each new process feature was cross-referenced
with an item in the Goal Service Model matrix to justify its introduction.
Figure 4.9: BMPN of the ‘to-be’ Business Process (Case Study 2)
Figure 4.10: Component Dependency Diagram (Case Study 2)
99
In the software service design, the project adopted the process
decomposition approach of SOMA [47]. The decomposed process is
combined with the Goal Service matrix to produce a software services
catalogue. The software design also included a Use Case diagram, Use
Case scenario, and Service Component dependency diagram (figure 4.10).
As standardized in SOMA methodology, these components were then
summarized in the SOA Architecture Diagram.
Figure 4.11 summarizes the framework adoption in this case study.
Figure 4.11: Adapted Service Engineering Framework (Case Study 2)
4.3.3 Case Study 3 – Accounting Information Service
Unlike the two previous case studies, this case study concerns less on
direct customer interaction and more on inter-organization interaction.
The service system under study is an internal accounting system which is
targeted to be able to provide more transparent information services.
To understand the context, the project began with composing the
business model into a BMC format. The high-level view of BMC does not
sufficiently explore potential scope for service innovation. To elaborate
Business
Modeling
Interaction
Modeling
Process
Modeling
Software-Service
Modeling
Business Service
DesignSoftware Service System Design
Requirement
Gathering
IDENTIFICATION DESIGN
Understanding
Service Context
Defining
Service Concept
Business
Service
Modeling
BMC(value, cust.
relation, channel)
Business
Service
Catalogue(features)
As-is
Service
Blueprint To-be
BPMN
Software
Service
Catalogue
Problems,
Directives,
Opportunities
SWOT
matrix
Feasibility
Study
Decomposed
Process
Software System
Modeling
UML
Use Case
Service
Component
Depedency
Diagr.
SOA
Reference
ArchitectureValue Chain
Model
Goal Service
Model
To-be
Service
Blueprint
100
the context comprehension, the Component Business Model (CBM) [94]
concept was adopted (figure 4.12). The CBM is able to highlight areas
within the competency map of the accounting office with potential
information services.
Budget strategy
and policy Financial administration
strategy and policy
Accounting strategy
and policy
Asset management
strategy and policy
Procurement strategy
and policyBudget realization
strategy and policy
Cash management
Periodic reports
managementAsset management
DAU fund managementFinancial management
Hibah fund managmnt
DAK fund management
SP2D issuance
Asset mainternanceAcquiring support staff
Operating accounting
application system
Budgeting Financial Admin. Accounting Asset Management General Admin
DPA verification
RAPBD setting Payroll issuance
Hibah budgeting Hibah disbursement Financial data servicePerformance reports
Direct
Manage
Execute
Business
competencies
Accountability
levels
Business
components
Targeted
business
components
Figure 4.12: Component Business Model (Case Study 3)
The potential service scope was identified in the CBM. It drives the
business process analysis in the targeted area which was later
documented in a BPMN format. In a qualitative manner these potential
scopes were filtered and prioritized based on the mandated directive
principles. The resulting list was then defined as a service innovation
opportunity.
A detailed service innovation proposition was then formalized into a
business service catalogue along with its features. A to-be BMC was also
created highlighting a modification on the components of (1) values and
(2) channels. During the identification stage, the existing structure of
application subsystems and its domain ontology were also assessed and
101
documented. The domain ontology is documented using an ER diagram
(figure 4.13).
-apbd_id : Integer
-tahun : Short
-jenis : Boolean
-tgl_kuappas : Date
-tgl_pembahasan : Date
-tgl_persetujuan : Date
-tgl_evaluasi : Date
-tgl_penetapan : Date
apbd
-ws_id : Integer
-nama_ws : Char
-method : Char
-deskripsi : String
-input : String
-output : String
-url : Char
ws-userws : Char
-hash : Char
-nama : Char
-waktu_daftar : Date
-skpd : Char
-aktif : Boolean
-password : Char
wsuser
-userws : Char
-ws_id : Integer
ws_authority
1
n
1
n
-username : Char
-password : Char
-waktu_daftar : Date
-aktif : Boolean
-grup : Integer
-nama : Char
-alamat : String
-email : Char
-telp : Char
users
-username : Char
-norek : Char
-namarek : Char
-bankrek : Char
-apbd_id : Integer
hibahbansos
-username : Integer
-skpd : Char
-unitkey : Integer
-userws : Char
instansi
11 1 1
-req_id : Integer
-username : Char
-uraian : String
-input : String
-output : String
-tgl_req : Date
-tgl_closed : Date
-balasan : String
req_data
1n
1
1
-anggaran_id : Integer
-username : char
-deskripsi : String
-pengajuan : Double
-tglberkas : Date
-tglterima_tu : Date
-tglterima_skpd : Date
-tglterima_bpkad : Date
-nilai_kuappas : Double
-nilai_apbd : Double
-st_perbaikan : Char
-url_proposal : Char
-userskpd : Char
-userbpkad : Char
angg_proposal -username : Char
-dekripsi : String
-pengajuan : Double
-tglberkas : Date
-tglterima_tu : Date
-tglterima_skpd : Date
-tglterima_bpkad : Date
-nospm : Char
-st_perbaikan : Char
-url_proposal : Char
-unitkey : Char
-cair_id : Integer
-userskpd : Char
-userbpkad : Char
cair_proposal1
1
1
1
-informasi_id : Integer
-username : Char
-unitkey : Char
-informasi : String
-balasan : String
-jenis : Boolean
-tgl_informasi : Date
-tgl_balasan : Date
informasi
1
n
1
n
-nospm : Char
-unitkey : Char
-nmunit : Char
-tglberkas : Date
-nosp2d : Char
-tglsah : Date
-norek : Char
-nmrek : Char
-bankrek : Char
-st_perbaikan : Char
-uraian_perbaikan : String
-tglcair : Date
-jmlsp2d : Double
-pph21 : Double
-pph22 : Double
-pph23 : Double
-pph4 : Double
-pph26 : Double
-ppn : Double
-keperluan : String
sp2d
1
1
-key : Char
-value : String
setting
n1
businessUnit
proposal_disbursed
proposal_budgeted
information
Figure 4.13: E-R Diagram (Case Study 3)
Business process design marked the beginning of the design stage.
Detailed BPMN were created to highlight the modification of business
processes. Introduction of new processes led to new operations assigned to
the business actors, presented in Responsibility Assignment Matrix. The
matrix defines actors assigned to each level of responsibilities:
Responsible, Accountable, Consulted, and Informed (RACI), as presented
in figure 4.14.
102
DPA verification
APBD setting
Hibah budgettng
Hibah disbursement
SP2D issuance
Financial data service
Hib
ah re
ques
ter
Offi
ce c
oord
inat
or
Bus
ines
s un
it ve
rific
ator
Bud
getin
g di
visi
on s
taff
Trea
sury
div
isio
n st
aff
Ban
kD
ata
requ
este
rA
pplic
atio
n op
erat
or
Bus
ines
s un
it tre
asur
er
Bud
getin
g se
ctio
n ch
ief
Trea
sury
sec
tion
chie
f
Bud
getin
g di
visi
on h
ead
Trea
sury
div
isio
n he
ad
Dep
uty
head
Hea
d
I
I R
R
R
R
R
R
R
R
R
R
R
R
I R
I
C
C
A
R
A
C
A
A C
A
R
A
C
A
A
A
Actors
Services
* R: Responsible (works on), A: Accountable, C: Consulted, I: Informed
A
I
I
I
I
I
Figure 4.14: Responsibility Assignment Matrix (Case Study 3)
Accommodating the proposed functionality, new data architecture
was also introduced in this stage. For the software service design, the
case study followed MSOAM guidelines [11] in breaking down processes
into operations, grouping operations into software service candidates,
normalizing service candidates, and structuring service dependency in a
layered approach. The MSOAM informal notation of software service is
used throughout the design which simply stated the service name and the
operations contained. To summarize the structure, a Service Architecture
was defined to a logical arrangement of four service layers from business
processes to physical data assets (figure 4.15).
103
Sistem layanan keuangan
Pengaturan APBD
Create_apbd
Update_apbd
Delete_apbd
Get_apbd
Authority
Add_authority
Delete_authority
Get_authority
Check_authority
APBD1
Create_apbd
Update_apbd
Delete_apbd
Get_apbd
Transaksi_berkas
upload
Penganggaran_Hibahbansos
Create_proposal
Edit_proposal
Delete_proposal
Get_proposal
Get_nodaftar
Update_status
Hibah_bansos
Create_hibahbansos
Edit_hibahbansos
Delete_hibahbansos
Get_hibahbansos
Informasi_proposal1
Create_informasi
Edit_informasi
Delete_informasi
Get_inf_proposal
Proposal_penganggaran1
Create_proposal
Edit_proposal
Delete_proposal
Get_proposal
Pencairan_Hibahbansos
Create_proposal
Edit_proposal
Delete_proposal
Get_proposal
Get_nodaftar
Update_status
Proposal_pencairan
Create_proposal
Edit_proposal
Delete_proposal
get_proposal
sp2d
create_sp2d
edit_sp2d
delete_sp2d
get_sp2d
Authentikasi
verify
instansi
Create_user
Edit_user
Delete_user
Get_user
Pengaturan_user
Create_user
Edit_user
Delete_user
Get_user
Progress_sp2d
Get_sp2dsah
Inform_sp2d
Post_sp2d
Get_spm
Update_status
Create_berkas
Delete_berkas
Pengaturan_permintaandata
Create_req_data
Edit_req_data
Delete_req_data
Get_req_data
Angg_real
Get_ar_skpd
Get_ar_skpd_prog
Get_ar_skpd_keg
Get_ar_skpd_prog
Get_ar_skpd_keg_bab
Get_ar_skpd_keg_kel
Get_ar_skpd_keg_jenis
Get_ar_skpd_keg_obj
Get_ar_skpd_keg_rinc
Get_ar_apbd
anggaran
Get_angg_skpd
Get_angg_skpd_prog
Get_angg_skpd_keg
Get_angg_skpd_prog
Get_angg_skpd_keg_bab
Get_angg_skpd_keg_kel
Get_angg_skpd_keg_jenis
Get_angg_skpd_keg_obj
Get_angg_skpd_keg_rinc
Get_angg_apbd
realisasi
Get_real_skpd
Get_real_skpd_prog
Get_real_skpd_keg
Get_real_skpd_prog
Get_real_skpd_keg_bab
Get_real_skpd_keg_kel
Get_real_skpd_keg_jenis
Get_real_skpd_keg_obj
Get_real_skpd_keg_rinc
Get_real_apbd
getdatamaster
Get_skpd
Get_urusan
Get_program
Get_kegiatan
Get_rekening
get_rka
get_rka
get_rkap
ws
Create_ws
Edit_ws
Delete_ws
Get_ws
userws
Create_user
Edit_user
Delete_user
Get_user
Req_data
Create_req_data
Edit_req_data
Delete_req_data
Get_req_data
Setting
check_cache
add_setting
edit_setting
delete_setting
get_setting
Kas
get_kas
get_penerimaan
get_pengeluaran
Orchestration Service Layer
Task centric business service
Entity centric business service
Utility application service
Accounting Service System
Setting_APBD Budgeting_HibahBansos Disbursement_HibahBansos Setting_User
Setting_DataRequestAuthenticationInfo_CashTransact
Info_BudgetRealization Info_Budget Info_Realization
Info_ProposalBudgeting_APBD Budgeting_Proposal Disbursement_Proposal
BusinessUnit
TransactArchive
Figure 4.15: Software Service Architecture (Case Study 3)
UML style notation was also used in the design documentation.
Sequence diagram were used to illustrate complex software service
interactions (figure 4.16). To communicate the design of software service
usage, service functionality was assigned to system actors in the form of a
Use Case diagram for each subsystem (figure 4.17).
104
Figure 4.16: Sequence Diagram in Case Study 3
Figure 4.17: Use Case Diagram in Case Study 3
Figure 4.18 summarizes the framework adoption in this case study.
Figure 4.18: Adapted Service Engineering Framework (Case Study 3)
Requester Progressp2d Services Authority Services
Status
Return Data
create_sp2d()
Check_authority()
sp2d Services
insert_sp2d()
status
Administrator
Bag Anggaran
badan/lembaga
SKPD verifikator TU Pimpinan
Bag VerAk
BJBpemohon data
Verification Budget Implementation Document
preparation of a draft budget
The budgeting grants and social assistance
The expenditure grants and social assistance
The issuance of sp2d
Request data
SKPD
Capturing Software
System Structure
Business
Service
Modeling
Process
Modeling
Software-Service
Modeling
Business Service
Design
Software Service
Design
Requirement
Gathering
IDENTIFICATION DESIGN
Understanding
Service Context
Defining
Service Concept
Business
Modeling
Business
Service
Catalogue(features)
BMC(value, channel)
To-be
BPMNSOA
Reference
Architecture(layers)
Directives, Opportunities
(prioritized)
As-is
BMC
Software
Service
Catalogue
UML
Use Case
Component
Business Model
(CBM)
As-is
BPMN
Business
Process
Analysis
RACI
matrix
Current
Application
Subsystem
Structure
Current Data
Architecture
(ER Diagr.)
Data Modeling
Modified
ER Diagram
Service
Depedency
Diagram
Service
Sequence
Diagram
105
4.3.4 Evaluation of Case Studies
Several observations can be drawn from the stages and activities
undertaken in the case studies. Some additional aspects are introduced in
the ‘Understanding Service Context’ activity in the ‘Identification’ Stage.
The first case study demonstrated that examining a current business
practice can be performed with a Business Process analysis technique, by
documenting and analysing the process in BPMN format. This also
demonstrates the implied implication of the selected ‘artefact’ format (i.e.
metamodel) to the detailed ‘how’ aspect (i.e. ‘technique’ component)in the
framework activities.
The third case study also shows that capturing a current business
model with BMC is feasible, but it can be considered insufficient in some
cases. A closer look at business unit capabilities with CBM provides
beneficial insight to the potential area of service enablement.
The ‘Understanding Service Context’’ sub-stage defines the scope for
a service enablement. The scope can be qualitatively derived from the
business mandate and identified problems in the current situation. The
resulting list of enablement opportunity can be further narrowed into a
priority based on identified important directives, as in the first and third
case study, or based on an analysis technique such as with SWOT
analysis.
The second activity of the identification stage is basically uniformed
with BMC format for business modelling and a business service catalogue
106
for business-service modelling. In the second case study, an additional
artefact for the business model is introduced to define and elaborate the
‘value’ concept brought to the business model from the service.
As an artefact, the business service catalogue is a list of enablement
targets enriched with service feature descriptions mandated for the
design stage. The second case study demonstrated that the list and its
features can be linked to the mandated directives using a Goal Service
Matrix. In a later stage, this matrix will be used to derive atomic
operations to be implemented.
The second case study also showed that, before entering a design
stage, an examination should be performed to understand the current
software system structure. This activity can be done in parallel with the
service concept definition activity.
For producing the ‘Process Model’ in the Design stage, the second
case study suggests that interaction modelling can be omitted for certain
type of service systems without direct customer-facing interaction, where
service transactions are performed mechanically through system
interactions. The second case study also introduced the use of the
Responsibility Assignment matrix (RACI) to summarize the assignment
of a process and operation to actors in the related business process
diagram (BPMN).
The re-designed business process also derives some consequences for
data entity modification. Therefore, a re-designing of data architecture
can be performed in conjunction with ‘Process Model’ design, before
107
entering the ‘Software-Service Design’ activity. This variation conforms to
the aspect of ‘ontology engineering’ in the broader context of service
engineering [82].
The ‘Software-Service Design’ activity in the design stage produced a
list of exposable software-services. This list is a result of combined
analysis of process decomposition and process-operation grouping service
goal referencing as demonstrated in the first and second case study.
Additionally, software-services could be regrouped into service-
components to be developed as software components in the software
development stage.
There are various graphical styles available in abstracting a
software-service: As a container with service name and operations (in
UML class, and MSOAM abstraction), as use-case ellipse (in use case
diagram), or as an UML component (in component diagram for software
development).
A structured relation between software-services is provided in three
manners: First, a UML-styled sequence diagram which shows the
sequential execution of software service operations in a complex multi-
service operation. Second, a dependency diagram which show the inter-
calling relation between software services. Third, in a SOA architecture
which summarizes all software-service dependencies in a layered format.
The importance of SOA architecture is shown by the fact that all of
the case studies provided the diagram. The dependency diagram is used
to elaborate service inter-relations in a bounded subsystem. It can also be
108
used to assess the grouping of software-services into software
components. The sequence diagram is only occasionally used to illustrate
the execution of complex orchestrated or composed software services.
In a technical level, a software-services catalogue lists services with
its associated operations and parameter options. The catalogue is also
accompanied with UML Use Case diagrams which specify the invoking
right of a software-service to certain actors. The actor itself can be a
human actor, e.g. customer or an automated process, i.e. application
system.
Accommodating all the variants of framework adoption in the case
study, a consolidated version of the framework prototype is visualized in
figure 4.19. Due to the dominant existence of legacy application systems
in case study 3, activities for capturing and analysing software systems,
i.e. software architecture and data architecture, are embedded in the
framework.
(to-be)
Business
Model
Interaction
Model
Process
ModelSoftware-Service
Modeling
Business Service
Design
Software Service
System Design
Business
Directives
IDENTIFICATION DESIGN
Understanding
Service Context
Defining
Service Concept
Business
Service
Model
(as-is)
Business
Process
Software
System
ModelOpportunity
Priority
(as-is)
Business
Model
Business
Capabilities
Service
Goal & Value
(as-is)
Software
Architecture
(as-is)
Data
ArchitectureData Model
BPMN
Business
Process
UML
Deployment
Diagram
Component
Business
Model
Service
Blueprint
Business
Model Canvas
UML
Class
Diagram
BPMN
Business
Process
ER - Class
Diagram
Service
Goal
Business
Goals
Business
Service
Catalog
UML
Use Case
UML
Component
Diagram
UML
Deployment
Diagram
UML
Sequence
Diagram
UML
Class
Diagram
Business
Model
Canvas
Software-Service
Model
Software Service
System Design
DESIGN
Software
System
Modeling
UML
Use Case
UML
Component
Diagram
UML
Deployment
Diagram
UML
Sequence
Diagram
UML
Class
Diagram
List of
Opportunity
Figure 4.19: Adapted Service Engineering Framework (Case Studies)
109
Omitting activities related to software-engineering in both stages,
the framework is simplified back to the service level context as the 2nd
iteration of the proposed framework (figure 4.20).
1.2.1
(to-be)
Business
Model
2.1.1
(to-be)
Interaction
Model
2.1.2
(to-be)
Process
Model2.2
Software-Service
Model
2.1 Business Service
Design
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Understanding
Service Context
1.2 Defining
Service Concept
1.2.3
Business
Service
Model
1.1.3
(as-is)
Business
Process
1.1.2
(as-is)
Business
Model
1.1.4
Business
Capabilities
1.2.2
Service
Goal & Value
2.1.3
Data Model
BPMN
Business
Process
Component
Business
Model
Service
Blueprint
Business
Model Canvas
UML
Class
Diagram
BPMN
Business
Process
Service
Goal
Business
Goals
Business
Service
Catalog
UML
Use Case
UML
Sequence
Diagram
UML
Class
Diagram
Business
Model
Canvas
2.2 Software Service
Design
2. DESIGN
1.1.5
Opportunity
Priority
List of
Opportunity
Figure 4.20: Service Engineering Framework (2nd iteration)
From the case studies, two additional concepts were emerged previously
uncovered by the framework: business unit capability (component 1.1.4),
and service value (component 1.2.2). Table 4.3 summarized these aspects
of service engineering.
Table 4.3: Service Engineering Modelling Aspects (from Case Study)
Modelling Aspect Related Concept
1 Business model Business model value-net [31], service customer [32]
2 Capability model Service-resource model[24], service entities [32]
3 Value model Service value-net [31], service goal [32], service linkage[32]
4 Service model Service-product[24]
5 Interaction model Service input-output [32]
6 Process model Service-process[24][32]
7 Software model IT enabler[32]
110
4.4 Service Engineering with SoaML
As exercised in the ontological chapter, the existence of the SoaML
specification is reused here as a comparison source with the tentatively
produced framework.
4.4.1 SpecificationofSoaML Activity Flow
Some metamodels are introduced embedded with a formal methodological
guidance on its usage, e.g. SOMF [59] and Archimate [95]. But other
metamodel specification are introduced independently and detached from
the usage guidance, e.g. UML [56]. SoaML is an example of the second
type where the actual usage pattern within an engineering process is to
be decided by the modeller.
SoaML specification explicitly declares that it supports both top-
down and bottom-up approaches in SOA development. The key difference
is in the departing point for service identification, which led to a flow of
subsequence process. The specification states five service identification
approaches facilitated by SoaML [60]:
1. Top-down A: Starting from the Services Architecture, as a
community of interacting participants, to individual Service
Contracts, as an interaction agreement toward further detailed
service identification.
111
2. Top-down B: From organizing functions into a hierarchy of
Capability to identify potential Service Interfaces that will expose
the capability as a service.
3. Top-down C: From Business Process within a specific purpose to
collect functional Capabilities and Roles related to Participant.
4. Bottom-up A: From assessing assets owned by Participants, as
potential Capabilities to be exposed as a service.
5. Bottom-up B: From an identification of common data and data flows
between parties, to be grouped into modules of services.
Business
Motivational
Directives
Business
(Functional)
Requirement
Business
Process
Capabilities
Service
Architecture
Business
Domain
Ontology
Service Data
Model
Service
Contract
Service
Interface(Composed
Service)
Interface(Atomic Service)
Service
ParticipantRole
Operation
Parameter
Method
Message
Interaction
Protocol
Service Component
Software
Component
Top
Down B
Top
Down A
Top
Down C
Figure 4.21: SoaML Top-Down Approaches Artefacts Flow
Adhering to the service engineering context of this research, in
which a service is not proposed from its underlying asset but instead
112
grounded on specific goals in a certain process context, the top down
approach is more appropriate to be adopted for the Service Engineering
Framework.
Operation
Parameter
Business
Directives
Business
(Functional)
Requirement
Business
Process
Capabilities
Service
Architecture
Business
Domain
Ontology
Service Data
Model
Service
Interface(Composed
Service)
Interface(Atomic Service)
Service
Participant
Method
Message
Interaction
Protocol
2.1.1
2.1.2
2.1.4
1.1.4
2.2.3
2.2.2
2.2.1
Service
ContractRole
2.1.31.2
2.2.4
1.1
Figure 4.22: Regrouping SoaML Artefacts into Activities
Interpreting and combining the top down approach, the sequential
dependence between artefacts can be visualized as a SoaML artefacts
flow in figure 4.21. Regrouping the SoaML artefacts produced a
stereotyped flow of the service engineering process. Figure 4.22 shows the
regrouping with activities and artefacts numbering correlated to the
framework in figure 4.23.
Replacing UML roles in the previous framework (figure 4.20) with
SoaML artefacts (figure 4.22) produces a modified framework (figure
4.23). A simplification of the framework, by omitting software-
engineering activities, produces the third iteration of the framework, as
presented in figure 4.24.
113
2.2 Software Service
System Design
2. DESIGN
2.2.5
Software
System
Modeling
2.1 Business Service
Design
2.1.2
Interaction
Model
2.1.3
Process
Model
2.1.4
Business Information
Model
2.1.1
Service
Architecture
Model
2.2.1
Atomic
Service
2.2.2
Composite
Service
2.2.4
Service
Detail
Model
2.2.3
Service Information
Model
2.2.6
Software
Data
Structure
UML
Component
DiagramUML
Component
Diagram
UML
Deployment
Diagram
SoaML
Service
Archit.
SoaML
Interface
SoaML
Service
Interface
SoaML
Message
Type
UML
Behaviour
SoaML
Participant
SoaML
Service
Contract.
BPMN
Business
Process
Service
Blueprint
UML
Class Diagram
1.2.1
Business
Modeling
(to-be)
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Understanding
Service Context
1.2 Defining
Service Concept
1.2.3
Business
Service
(to-be)
1.1.3
Business
Process
(as-is)
1.1.5
Opportunity
Priority
1.1.2
Business
Model
(as-is)
1.1.4
Business
Capabilities
1.2.2
Service
Goal & Value
(to-be)
(1.1.6)
Software
Architecture
(as-is)
(1.1.7)
Data
Architecture
(as-is)
BPMN
Business
Process
UML
Deployment
Diagram
Component
Business
Model
Business
Model Canvas
Class
Diagram
Service
Goal
Business
Goals
Business
Service
Catalog
Business
Model
Canvas
UML
Component
Diagram
Activity
Artefact
Modeling
ToolOpportunity
List
Figure 4.23: Incorporating SoaML Artefacts into Framework
2.2 Software Service
Design
2. DESIGN
2.1 Business Service
Design
2.1.2
Interaction
Model
2.1.3
Process
Model
2.1.4
Business Information
Model
2.1.1
Service
Architecture
Model
2.2.1
Atomic
Service
2.2.2
Composite
Service
2.2.4
Service
Detail
Model
2.2.3
Service Information
Model
1.2.1
Business
Modeling
(to-be)
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Understanding
Service Context
1.2 Defining
Service Concept
1.2.3
Business
Service
(to-be)
1.1.3
Business
Process
(as-is)
1.1.5
Opportunity
Priority
1.1.2
Business
Model
(as-is)
1.1.4
Business
Capabilities
1.2.2
Service
Goal & Value
(to-be)
Activity
Artefact
SoaML
Service
Archit.
SoaML
Interface
SoaML
Service
Interface
SoaML
Message
Type
UML
Behaviour
SoaML
Participant
BPMN
Business
Process
SoaML
Service
Contract.
Service
Blueprint
UML
Class Diagram
BPMN
Business
Process
Component
Business
Model
Business
Model Canvas
Service
Goal
Business
Goals
Business
Service
Catalog
Business
Model
Canvas
Modeling
Tool
Opportunity
List
Figure 4.24: Service Engineering Framework (3rd iteration)
114
4.4.2 Case Study with SoaML
The three preliminary case studies use UML in modelling the software
service. UML adoption is fairly sufficient for modelling a simple software
service system. But as also evident in the previous case studies, UML
lacks standardized notations to represent the service concepts. To verify
the usability of SoaML as a service modelling language in a complex
service system, a larger case study is performed.
The case study operates in the larger context of implementing a
smart campus initiative within a university-wide scope. The project
covers a complex system of services involving multiple participants,
including students, lecturer, administrative staff of various business
units, and external providers.
Figure 4.25: Package Diagram of Project Domains (Smart Campus)
115
The project is divided into six domains (figure 4.25). The project
directives, i.e. service objectives, are defined for each domain before
detailing the domain into several service systems.
Figure 4.26: Catalogue of Software-Services (Smart Campus)
In total, there are 18 sub-systems to be detailed as service-systems
under the 6 domains (figure 4.26). This boundary of service systems
serves as a container for individual software services to be introduced and
defined in the design stage.
Smart Learning
Management System
Personalized Learning
SystemSmart Classroom System
Library Management
System
CourseSchedulingApproval CourseLearning ClassroomRequest BookLoan
CourseSchedulingProposal LearningProfile ClassroomVerification BookReturn
CourseExam LearningReport InventoryMaintenance BookRecommendation
CourseMaterial PerformanceLog ClassroomReport InformationSharing
CourseDiscussion ProgressTracking ClassroomScheduling Reminder
EnrollmentApproval CourseContentUpload ClassMeetingRealization CollectionCatalogue
Enrollment CourseTreatment VirtualClassroom LibraryReport
ClassOffering ClassroomRecording
LecturerPlan Notification
AcademicAdvisor WebLecturing
TeachingAssignmentLetter Assessment TeachingEvaluation
LearningManagementReport TaskCollecting Authentication [SSO] StudentEvaluation
Notification TaskScoring CourseEvaluation
CourseSyllabus AchievementEvaluation Notification ClassroomEvaluation
ProjectGroupManagement AssessmentReport ManagementDashboard
Campus GISPeople Identification
System
Bathroom Management
System
Smart Attendance
System
AssetInformation Registration WaterUsage StaffAttendance
LocationTracking PeopleProfiling BathroomAvailability CourseAttendance
SpatialData Validation BathroomCleaning Notification
PersonalAgenda PeopleMovementReport BathroomCapacity AttendanceReport
Notification Notification AttendanceLog
ParkingSlot AssetControl WasteMonitoring ContentManagement
ParkingCounter EnergyUsage WaterMonitoring SearchEngine
ParkingPayment SpaceUsage Distribution NewsTracking
ParkingRequest RealTimeWarning Maintenance Notification
Notification Maintenance Report NewsRating
DisasterInformation Report NewsComment
Finance System Office SystemMarket Management
System
Health Monitoring
System
SmartPayment SmartMeeting OrderProcessing PatientRegistration
ManageBalance MeetingSchedule StaffAssignment MedicalRecord
Invoice MeetingNotes Shipping Pharmacy
Notification MeetingReminder ProductStore HealthMonitoring
FinancialReport FileSharing Scheduling HealthScheduling
BalanceSheet OfficialLetter Prescription
Budgeting
FinancialGrowth
AssetAndInvestment
Teaching Management
System
Smart Parking SystemWaste and Water
Management System
Assessment System
Smart Building SystemNews Management
System
116
In general, the project follows framework guidance:
Business directives are captured as business goals (table 4.4), to
derive service requirements to be meet as service goals (table 4.5).
Both artefacts take the form of a structured narrative presented in a
form of a table.
Business Model Canvas (BMC) is used to assess the business
context, as a basis for (software) services introduction. BMC is
produced both in ‘as-is’ version during identification stage and in ‘to-
be’ version in the design stage.
BPMN diagram is used to capture the existing business process
during the identification stage and defined during the design stage
to elaborate on the process supporting the proposed business model.
Service Blueprint is used in parallel with BPMN but only in the
design stage to highlight the interactions processes expected from
the consumer for each service system.
Occasionally, a high level view of interaction between a participant
and the targeted service system is provided in the form of a context-
diagram, which could take the form as a Data Flow Diagram (DFD) style
context diagram as suggested in [62], or as a UML use case.
117
Table 4.4: Sample of Business Goals (Smart Campus)
Table 4.5: Sample of Service Goals (Smart Campus)
The main difference with the first cycle of case studies is in the use
of SoaML to replace UML’s role in service modelling. For illustrative
purposes several artefact samples are presented here.
Figure 4.27: SoaML Capability Diagram (Smart Campus)
Domain Service Strategy and Objectives
Smart
Learning
1) improve collaborative learning between lecturers and students;
2) provide equal opportunities for all students to study without
being limited by distance and time;
3) support self learning in accordance with the correct path; and
4) evaluate learning competency achievement (self assessment).
Smart
Management
1) face recognition to avoid crime or to record people who are in a
particular area;
2) trace the movement or mobilization of people to know the
distribution of humans at certain times;
3) smart cards to provide parking permits and non-cash
transactions;
4) recording attendance on a teaching and learning activity.
Smart
Governance
1) enable internal and external campus governance at multiple
stakeholder levels;
2) establish, monitor, implement and evaluate short, medium and
long-term
work plans;
3) process governance to improve organizational performance
through optimization, root cause analysis, and improvement of
preventive and corrective actions;
4) present a management workflow that supports automated
reporting and scheduling, logging, and adaptation capabilities on
configuration changes
Smart Social 1) identify student profiles so they can group them according to
student interests;
2) perform sentiment analysis in accordance with data stored on
social networks;
3) improve the service at the right time and location in accordance
with student interests
Smart Green 1) energy creation and consumption intelligently;
2) buildings management that is energy efficient and
environmentally friendly;
3) implementation of sensor technology for accurate reporting
SmartHealth 1) health services anytime and anywhere to the campus residents;
2) intelligent information systems that can report the level of
health on campus, for example: reporting the extraordinary events
of a disease;
3) proactive or preventive health services;
4) tracking and recording of campus health status in general
Services
SystemsServices Systems Requirements
Smart
Learning
Management
System
a. should be able to meet the needs of recording data relating to teaching activities,
including the course syllabus, meeting schedule, student attendance, project group
creation, and the provision and execution of tasks.
b.should also be able to manage and set the main supporting data of teaching process
Personalized
Learning
System
a. should be complemented by the concept of adaptive learning
b. providing feedback on achieving current learning outcomes in intelligent learning
environments.
c. may include: learning objectives, plans, learning maps, learning activities,
competence levels, performance or achievement of learning outcomes, and reflections
Assessment
System
a. recommendations generated based on behavior and learning progress.
b. the tests used as the basis for capability assessment can be made in various
models, such as essays, practices, multiple choice, matching, and short answers.
c. providing automatic grading and create performance reports like score distribution
and statistics of student learning outcomes.
d. presenting the results of a comprehensive data analysis
Smart
Classroom
System
a. should be able to presents a virtual classroom (VC) concept to replace classes
physically
b. should also be able to present real teaching atmosphere
c. the access media used by students to interact through VCs can use any mobile
phone, tablet, computer, or other supportive equipment
d. should be able to manage their study space personally by following a series of
teaching process
Library
Management
System
a. should be able to to improve library services such as borrowing and returning
books independently, storage information of shelves, book catalogs, and cart.
b. at the same time, library members can also look for books that are being borrowed
by other members
Smart
Attendance
System
should be able to record the presence of students and lecturers/employees so as to
monitor their presence in the campus
People
Identification
System
should be able to record data of each campus visitors, including students,
faculty/staff, and guests . These records are used to control campus security by
verifying and validating campus visitors.
Campus
Geographic
Information
System
a. should be able to present information using maps or augmented reality technology
to help direct a visitor to a particular place/location based on his current position,
complete with the route to go through.
b. should be able to monitor visitor’s movement or even goods appropriately.
Bathroom
Management
System
a. should be able to detects water management by reading the level of water use in the
bathroom and is analyzed continuously.
b. ahould be able to report analysis results in realtime.
c. should be able to provide information on the status of the bathroom, which can be
accessed also by students
Smart Parking
System
should be able to perform available parking or parking slot information, restrictions
on parking usage, and disaster information involving vehicles in the parking area
Teaching
Management
System
should be able to produce reports relating to the transaction teaching process,
including the realization of teaching hours; the realization of course syllabus;
percentage of teaching (attendance of lecturers and students); course graduation
percentage; feedback or student satisfaction level; occupancy of classroom use.
Financial
System
should be able to present reports relating to financial transactions, including the
balance sheet; activity plan and budget; periodic financial growth; investment and
asset value owned by the university
Office
System
a. should be able to provide services to university management with specific
capabilities such as the management of official letters; management of management
review meetings; teleconference, video conference, and application sharing;
b. should be able to perform the making of reports periodically with the support of
data stored in the database
Market
Management
System
a. users can compare similar products laterally to choose according to their individual
request character
b. can browse relevant products on the page freely
c. can choose products and keep doing ordering operations, including choosing
payment method, shipping method, etc
News
Management
System
a. should be able to facilitate users to rapidly check information on digital campus
platforms,
b. should be able to share information synchronously (chat,whiteboard, group
browsing)
Smart
Building
System
a. should be able to to support the process of automation in a building
b. should be able to record infrastructure facilities with precision and intelligence,
access to control facilities available on campus and carried out easily campus
monitoring and surveillance
c. should also be able to generate reports to university management, such as energy
usage (consumption) reports, real-time warning, energy and space usage patterns, etc.
Waste and
Water
Management
System
a. should be able to manage water and waste properly
b. should be able to report the water and trash conditions in the campus environment
in real time so that it can be made a decision as a follow-up when inappropriate
conditions were found
Health
Monitoring
System
a. should be able to provide health monitoring services for academic communities
b. should be able to maintain a qualified healthcare services in order to increase the
effectiveness of teaching and learning process and work productivity
118
The project adopted SoaML’s “Top Down B” and “Top Down C”
approaches in which the service identification departs from the business
process[77], and optionally via a capabilities set collected from the process
(figure 4.27). The produced SoaML’s capability diagrams serve as
templates for service candidates, and service interfaces.
.
Figure 4.28: SoaML Service Interface Diagram (Smart Campus)
Services are defined with SoaML’s Service Interface as a composite
usage of an atomic Interface (figure 4.28). SoaML Interface lists the
available operations available to be invoked by partnering participants.
The interaction protocol, which specifies the sequence of invoked
operations, is presented in UML’s sequence diagram within the service
interface definition. Additionally, descriptive rules for service
engagement are presented within SoaML’s service contract diagram, e.g.
minimal number of items ordered.
These service components, i.e. interface and service interface, are
collected into a service container as a SoaML’s participant diagram
(figure 4,29). In the participant diagram, the service (SoaML’s service
119
interface) becomes a participant port, and the interface becomes a spoke
or a socket protruding from the port.
Figure 4.29: SoaML’s Participant Diagram (Smart Campus)
Finally, the whole service components are tied and collected into
SoaML’s service architecture, covering participants, and services involved
(figure 4.30).
Figure 4.30: SoaML’s Service Architecture (Smart Campus)
4.4.3 SoaML Case Study Evaluation
SoaML may have weakness in its ambiguity and overlapping of
service abstraction, but compared to the use of UML, the superiority of
120
SoaML is evident during the case study. A comparison between the two is
provided in table 4.6.
Table 4.6: Comparison of SoaML and UML for Service Modelling
SOA Concept SoaML Representation
UML Representation
1. Service Interface, Service Interface <<service>> stereotype of class or interface
2. Atomic Service Interface <<service>> stereotype
3. Composite Service Service interface, Service contract Usage dependency of <<service>>
4. Service Architecture Service Architecture (High level) Use Case diagram
5. Element Participant, Component <<entity>> stereotype, Component
6. Endpoint Port in Participant. Port in component
7. Capability Capability, Participant behaviour (as a set of operation and method)
Class operation and method
9. Service interface Interface, Service Interface Interface
10. Service Contract Service Contract -
11. Role Role (in Service Contract, Service Interface and Service Architecture)
Actor specialization, or actor to use case association line
12. Information Type Message Type Data type
Despite its complexity, SoaML is considered to be better in
abstracting SOA concepts, as partially reflected in [63]. Elaborating point
3, 4, 5, 9 and 11 of the comparison table, SoaML can be considered
superior due to the lack of several features in UML:
SoaML provides better traceability in tying the related design
components during the definition of a service composition (service
interface and interface), its interaction protocol behaviour (sequence
diagram behaviour of service), toward the definition of service
121
components (participant) through the service architecture
(participant and service).
SoaML facilitates explicit separation between a service interface and
the service implementation. Consequently, the concept of ‘role’
within a service and ‘role-binding’ during service interactions can be
clearly presented. A particular participant can be abstracted to
assume more than one role within the scope of a service
architecture.
SoaML is able to represent a service system involving multiple
provider roles, in the form of number of roles defined in the service
interface and service contract diagram.
Considering these features, SoaML can be suggested as a metamodel
for complex service system, which is able to accommodate certain types of
business models with various assumable roles and multiple service
providers.
While ‘Service Architecture’ is part of SoaML diagrams, it is actually
more applicable for the non-IT context, i.e. non-software service. Service
architecture visualises the interrelation between participants within a
service community, adopting a certain business model for each
participant. Therefore, its usage in the framework is placed in the
‘Business Service Design’ activity (activity 2.1, artefact 2.1.1).
122
The same assessment can also be given to ‘Service Contract’ and
‘Capability’. Service contract is mostly derived from descriptive business
rules and agreement in conducting service interactions, while capability
relates to intrinsic capacity owned by a participant. Unless the rules and
capacity relate to automatic features of a software service, they reside
outside the boundary of ‘Software-Service Design’ activity.
Service architecture is useful in a business context to define the
scope of the analysis and design. Certain participants may be defined to
be an external party, which is beyond managerial control of the service
system, but adheres to a mutually agreed collaboration rule and protocol.
SoaML actually provides a way to define an external participant in the
form of a participant with a dashed-line boundary [60].
The key differentiator between a manual service and software
service is the type of Participant involved. For software-services, both
interacting participants are software component. Consequently, all
participants defined in the ‘Software-Service Design’ activity must be
implemented as software components in the implementation.
This chapter has defined a proposed and tested framework of
‘service engineering’. In the next chapter, the framework will be verified
with the ontologies of the third chapter in terms of its coverage
sufficiency. An identification of a stereotyped format for an artefact is
also drawn. The next chapter explores the metamodel landscape to
identify potential format for each framework’s artefacts.
123
Chapter 5
Modelling in Service Engineering
5.1 Metamodel Exploration
This chapter provides format elaboration for each artefact from activities
in the Service Engineering Framework. The artefact is essentially a
model representing partial aspects of the service system under study. The
model is build based on a specific modelling language convention, i.e.
metamodel.
Framework vs
Ontology
Mapping
Metamodel
Exploration
Service
Engineering
Framework(Generalized)
Service
Engineering
Ontology
Service
Engineering
Framework(3rd iteration)
Figure 4.24Figure 3.12
Table 3.22
Metamodel
Landscape
and Groups
Figure 5.5
Sec 5.1
Alternatif
Metamodel
Identification
Sec 5.2
Sec 5.3
Literature
Review
SOA
Literatures
Classic Service
Engineering
Service
Engineering
Framework(1st iteration)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
Software Service
Ontology
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework(3rd iteration)
Literature Review
Framework (RQ2, RQ3, RQ4) Ontology (RQ1)
Modeling (RQ4)
Ch 4
Ch 2
Ch 3
Ch 5
IntroductionCh 1
ConclusionCh 6
Case Study
(Second Round)
Service
Engineering
Framework(Generalized)
Activity’s
NarrationArtifact
Legend:
Section
Number
Sec # Figure #.#
Artifact
Number
Figure 5.23
Figure 5.1: Research Flow and Content Map (Chapter 5)
Figure 5.1 illustrates the content of this chapter with regard to
research activities flow. The chapter is divided into three parts. The first
124
part explores the current landscape of metamodel in the objective of
collecting a palette of potential metamodels to be included in the
framework. The second part examines the framework in terms of
artefacts coverage to the ontology to assess the completeness of the
framework and characterize the metamodel suitable for the artefacts.
Finally, the third part combines the previous two results to enrich the
framework with alternative potential metamodel.
5.1.1 Defining Model
Models hold a significant role in software engineering throughout its
evolution. Since the adoption of flowchart [96], the modelling approach
has shifted on several occasions; from the structured programming
paradigm [97], to object-oriented, with Unified Modelling Language
(UML) [98], and more recently toward a service-oriented approach [99].
The importance of modelling in software engineering is further
strengthened by the emergence of Model Driven Engineering [100], in
which modelling becomes the core of the engineering activity, and the
coding is mainly performed mechanically with automated machine
assistance, theoretically making the process becomes more efficient and
adaptive to changes.
The last two decades witnessed an unprecedented proliferation of
modelling languages, or metamodels. Domain disciplines, and industrial
practitioners, propose metamodels for a specific purpose or with general
125
applicability in mind. A consortium for standardized metamodels, the
Object Management Group (OMG), has published no less than 70 model-
related specifications since their first UML specification in 1989 [101].
In its most generic form, a model is defined as a “simplified view, or
abstraction, of reality” [102]. More formally, ‘model’ is defined as:
“a set of statements about a system under study”[103].
“a set of formal elements describing something being developed that
can be analysed using various methods” [104].
From these definitions a model can be summarized as an abstraction
format, representing an underlying object. A model is typically required
for two reasons. First, the object might be too complex to comprehend in
its original size and details. Second, the concept might not be discernible,
either as an abstract concept or is not yet materialized.
“as-is”
model
“could be”
model
What
“is”
What
“could-be”
Existing – Implicit
(Current)Preferred – Explicit
(Future)
Distilled to Manifest as
Researching PrototypingInterpret
Describe
Abstract
Concrete
suggest
Figure 5.2: Analysis-Synthesis Bridge Model[105]
The model definitions imply the purpose and activities surrounding
a model, i.e. studying and developing. In this context, the “bridge-model”,
126
as visualized in figure 5.2 summarizes the roles of models in engineering
[105]. Model is based on an object, and the model can represent the object
in various periods: past state, current state (“as-is”), or a future state
(“could-be”, “to-be”).
An engineering process can be seen as a transition from problem
domain to solution domain [61]. During the analysis phase, the “as-is”
models from the “problem domain” are composed to gain an
understanding of the current situation, to identify the problems, to
examine the needs, and to decide upon a specific requirement. During the
design phase, the “to-be” models from “solution domain” are created in
which a future state or a specific solution is proposed. During these
phases, model serves as a communication and collaboration tool among
involved parties, within a project team or with the stakeholders.
Besides serving as a communication and collaborating tool, a model
can also serve as a verification and validation tools during the early
engineering phases, e.g. prototyping in agile forms of software
engineering. In some cases, the models are gradually elaborated in detail
toward later stage of design to pinpoint a specification and to avoid
interpretation variance during the implementation phase.
5.1.2 Model Taxonomy
As an abstraction tool, model can be composed in various format, e.g.
textual, or graphical format [106]. Textual model presents its information
127
as a sequence of characters. Narrated description of a situation and
declarative languages (e.g., OWL, RDF) are some examples of textual
modelling. A graphical model on the other hand, uses a spatial
arrangement of graphic and text elements to convey the information.
Graphical models can also be categorized as two-dimensional models,
while the linear representation of textual model as one-dimensional.
Graphical models possess several advantages compared to a textual
model [106]. First, a diagram conveys its information in a concise
manner, while still retaining some degree of precision. Second, a diagram
facilitates a faster cognitive comprehension compared to a textual
description. This is due to its parallel presentation format, compared to
the serial presentation of textual form. Third, graphical information
typically can be cognitively processed and retained more efficiently due to
the nature of the human brain.
On the other hand, textual representation generally possesses a
higher expressive power compared to a graphical form. Textual form has
a wider flexibility for varying expressions due to less restrictive
vocabulary options. Also, due to the similarity to a natural language, the
learning curve for a textual language is relatively shorter compared to a
graphical language. For a graphical model, the understanding of the
notation vocabulary is a necessity. Despite these disadvantages, a person
normally prefers graphical representation over textual form due to its
efficiency and conciseness [106].
128
5.1.3 Metamodel Anatomy
A clear distinction should be made between a model and a modelling
language. To represent an underlying object, a model is created based on
a specific modelling language, i.e., a metamodel specification. The
specification sets the convention for creating and interpreting a model.
Semantics
Abstract
Syntax
Concrete
Syntax
Represented as
Define
meaning
Define
meaning
(derived)
Figure 5.3: Metamodel components[107]
Figure 5.3 illustrates components of a metamodel and their relation
in functioning as a language, which are [107]:
Abstract syntax, which defines metamodel conceptual coverage by
defining a set of covered concepts and its relational structure, i.e.,
metamodel ontology.
Concrete syntax, which declares a library of available
representational forms, such as elements, primitives, or notations,
along with the combination rules.
Semantics, which provide interpretative translation, by relating
each element (or combinations of elements) in the syntax to a
meaning.
129
The concrete syntax is an important reference point for creating or
understanding a model. The concrete syntax also differentiates graphical
metamodel with its textual counterpart. Textual metamodels defines its
syntax in ‘word’ forms while the graphical metamodel uses visual forms,
collected into a Graphical Concrete Syntax (GCS). GCS is theoretically
specified in three parts [106]:
Graphical symbols, specifying a library of notational symbols,
including the option for embedding textual information for a
notation label.
Compositional rules, which defines the notation combinatorial rules
and its feasible nested structure.
Visual semantics, which provides a mapping between graphical
symbols to the elements of the abstract syntax to define a meaning
to a symbol, or a group of symbols.
Considering the superiority of a graphical over textual metamodel,
this research focuses on the graphical metamodel. It should be noted that
the difference between textual and graphical metamodels is not always
clear. A narration written in natural language can obviously be
categorized as a textual model, but some formalized declarative
languages occasionally offer an option to arrange its elements in a spatial
structure, e.g., partitioned box, associative line. In this case, exception is
made to include these special types of textual metamodels.
130
5.1.4 Building Metamodel Landscape
In pursuing a cross-disciplinary engineering initiative, as in ‘service
engineering’, a structured collection of relevant metamodel options might
be beneficial. Several previous attempts have been made to collect
metamodel offerings, but mostly limited to certain specific domains, e.g.
service-oriented system [54], business process [108], or enterprise [109].
A structural map, as a navigational tool, to understand the relation
between metamodels and their position in the modelling landscape is
produced in this research. Detailed comparisons between metamodels has
been discussed in other studies, but they were mostly performed between
two metamodels, e.g. [110][111][112]. Only a few studies examine the
relation between more than three metamodels, e.g. [113].
Metamodels collected in this chapter were gathered from a literature
survey conducted in four disciplines: software engineering, e.g. [114],
system engineering, e.g. [115], enterprise architecture, e.g. [116][117] and
service engineering. Two interrelated sub domains were covered from the
service engineering domain: business-side service engineering, e.g. [26],
and informatics service engineering, e.g. [53]. Several additional
disciplines were also inevitably traversed during the lateral exploration of
metamodels, namely the Business Process Management and Financial
Accounting.
Due to the selection process during the exploration, an exhaustive
list of metamodel is not claimed in this chapter. An effort has been made
131
to ensure the representativeness of selected metamodels by cross-
checking to additional sources. Informal emphasis was made toward a
more recent and academically popular metamodel. A certain degree of
emphasis was also made toward service engineering-related metamodels.
Rather than adopting a pre-defined structure for mapping the
metamodel, an exploratory approach is taken, in which a structure was
derived from the metamodel set [118][119]. Each selected metamodel is
coded with two attributes: ‘scope’ and ‘keywords’. Scope relates to the type
of underlying object commonly represented in metamodel usage.
Keywords are assigned to provide certain characteristics to a metamodel
based on its central themes.
5.1.5 Metamodel Landscape
In literatures, the term ‘model’ and ‘metamodel’ are often used loosely.
Due to its strong correlation [120], metamodel often introduced with a
prescriptive engineering method, forming a ‘framework’. In this case the
name of the metamodel could be shared with its method counterpart. In
other cases, the terms are also used interchangeably with a ‘reference
model’’ (or ‘conceptual’ model), in proposing an ontological structure (i.e.,
grouping and relating concepts) of a domain, akin to an abstract syntax
definition.
To be included in the collection, the source is verified for the
existence of a graphical concrete syntax specification. In most cases, a
132
formal definition is omitted, and the specification is presented in the form
of examples. While this approach conveys the concepts and conventions in
a practical term, the lack of formalism risks of multiple interpretations.
The exploration produces a list of 53 selected metamodels. At the
beginning, the collection process strives for completeness, by covering
both older and newer metamodels. Older metamodels are included not
only for historical reasons, but also due to the fact that these metamodels
have never been formally fully retired and are potentially still used by
certain communities. The approach later shifted toward
comprehensiveness by omitting metamodels decided to be redundant or
too minor.
The ‘scope’ coding is drawn from several options of source: from
stated objective in the original introduction, from explanatory example
given, or from case studies performed. Two initial simplified codes for
‘scope’ are used: “software” and “business”. A model is either used to
represent a software system (including its underlying IT components), or
an (organizational) business system.
Later, a new type of metamodel is emerged that interchangeably
cover both the software and business aspects of an organization. A third
‘scope’ is then introduced to categorize them as “enterprise” metamodels.
A fourth minor scope also arises from certain type of metamodels which
are not specifically tied to the two initial scopes, but rather to a generic
definition of a system, covering even a physical system. This type of
metamodel are then coded with ‘system’ label in their scope.
133
Some observed metamodels can be categorized as a ‘family’ of
language, by offering several types of diagram to cover multiple aspects of
its underlying object, e.g., class, component, collaboration diagram in
UML. Asterix (*) symbol is added after the ‘scope’ code for metamodels
with more than two types of diagrams
The ‘keyword’’ codes are assigned to describe the characteristic of a
metamodel. It is arbitrarily derived from the core theme, important
concept, or special unique aspect represented by the metamodel. To be
useful as a grouping mechanism, the assignment of keywords is
coordinated among metamodels to limit the variance of a keyword. Up to
three keywords are coded to each metamodel, stated in descending order
based on its importance.
To convey a structure of the metamodel landscape, the coded
metamodels are presented both in tabular and graphical format under a
pre-ordered arrangement [121]. To form a continuous structure, the
tabular presentation is sorted in the order of the ‘scope’, followed by the
‘keyword’. As listed in table 5.1, the sorting is arranged from abstract
concepts to more concrete concepts.
Graphical representation is created by focusing on the relationship
between metamodels (figure 5.4). Relationship is drawn from three
perspectives: (1) similarity, (2) evolution and (3) compatibility. Similarity
is based on the coding assigned to metamodels. Similarity is visualized by
positioning similar metamodels close to each other around a tag of shared
code.
134
Table 5.1: Metamodels Set (Coded and Sorted)
Name Curator Year Scope Keywords Ref
1 GoalML (Goal Modelling Language) - 2014 Enterprise* goal, actor, structure [122]
2 MEMO (Multi-perspective Enterprise Mod) - 2011 Enterprise* goal, process, organization [123]
3 KAOS (Knowl. Acquisition in Automated Spec.) - 1991 Enterprise goal, structure [124]
4 GRL (Goal Oriented Requirement Lang.) ITU-T 2003 Enterprise goal, structure, distribution [125]
5 i* (Distributed Intentionality) - 1995 Enterprise goal, structure, distribution [126]
6 UEML (Unified Enterprise Mod. Lang.) Interop-NoE 2002 Enterprise goal, structure, ontology [127]
7 ODM (Ontology Definition Metamodel) OMG 2009 Enterprise* ontology, concept, rule [128]
8 ARIS (Architecture of Integrated Info. Syst.) AG Soft 1994 Enterprise* organization, process, product [129]
9 SoaML (Service oriented archit. Mod. Lang.) OMG 2009 Enterprise* service, architecture [60]
10 SOMF (Service Oriented Modelling Framework) Meth. Corp. 2008 Enterprise* service, architecture [59]
11 Archimate (Architecture of Integrated Info. Syst.) Open Group 2009 Enterprise* strategy, business, application [95]
12 E-BMM (Enterprise BMM) - 2009 Enterprise strategy, business, application [130]
13 BMM-IT+ (Business Motivation Model extension) - 2013 Enterprise strategy, structure, alignment [131]
14 BMM (Business Motivation Model) OMG 2008 Business strategy, goal, influencer [132]
15 b-SOAML (Business SOAML) - 2012 Business architecture, service [133]
16 BMI Cube (Business Model Cube) NEFFICS 2013 Business model, innovation [134]
17 BMC (Business Model Canvas) - 2010 Business model, innovation [85]
18 S-BMC (Service Business Model Canvas) - 2014 Business model, innovation, service [135]
19 SoBM (Service Oriented Business Modelling) - 2017 Business model, innovation, service [9]
20 SDBM (Service Dominant Business Model) - 2014 Business model, innovation, service [136]
21 CBM (Component Business Model) IBM 2005 Business capability, structure [94]
22 CM (Capability Map) - 2011 Business capability, structure [137]
23 VDML (Value Definition Modelling Lang) OMG 2015 Business* value, capability [138]
24 e3-value (Economic e-Commerce Value) 2001 Business value, exchange [139]
25 Value net - 2002 Business value, flow [140]
26 ServiceML (Service Modelling Lang.) SINTEF 2013 Business* service, goals, interaction [141]
28 SJML (Service Journey Modelling Lang.) SINTEF 2013 Business service, interaction, customer [142]
29 CJM (Customer Journey Map) IDEO 1999 Business service, interaction, customer [89]
30 PCN (Process Chain Network) - 2012 Business service, interaction, value [143]
31 SBP (Service Blueprint) - 1984 Business service, process, interaction [88]
32 POA (Possession-Ownership-Availability) - 2015 Business process, value, exchange [144]
33 Value stream - 1998 Business process, value [145]
34 SBVR (Semantics of Business Vocab. & Rules) OMG 2008 Business ontology, rule [146]
35 TDM (The Decision Model) KPI 2009 Business decision, rule [147]
36 DMN (Decision Model and Notation) OMG 2015 Business decision, rule [148]
37 CMMN (Case Management Model and Notation) OMG 2009 Business case, structure, state [149]
38 BPDM (Business Process Def. Metamodel) OMG 2008 Business process, collaboration [150]
40 BPMN (Business Process Model and Notation) OMG, ISO 2004 Business process, flow [151]
41 EPC (Event Process Chain) AG Soft 1992 Business process, flow, structure [152]
42 REA (Resource-Event-Agent) - 1982 Business process, structure, ontology [153]
43 UML (Unified Modelling Lang) OMG, ISO 1997 Software* object, function, behaviour [56]
44 YAWL (Yet Another Workflow Lang.) YAWL Found. 2002 Software process, flow [154]
45 DFD (Data Flow Diagram) - 1974 Software process, flow, data [97]
46 IFML (Interaction Flow Modelling Lang.) OMG 2015 Software interface, flow,user [155]
47 SC (Structured Chart) - 1988 Software flow, structure [156]
48 ERD (Entity Relationship Diagram) - 1976 Software data, structure, ontology [157]
49 SysML (Systems Modelling Lang) OMG, ISO 2006 System* block, functional [158]
50 IDEF (Integration Definition) KBSI 1995 System* function, data, process [159]
51 Flowchart ASME 1947 System process, flow [160]
52 Statechart - 1987 System state, transition [161]
53 Petri net - 1962 General flow, queue [162]
135
Figure 5.4: Metamodel Relationship (arranged in similarity)
The evolutive relationship is based from the existence of influence
from an older metamodel in the creation of a new metamodel. In some
cases, the new metamodel made the influencing metamodel obsolete. In
other cases, the influencing metamodel is only taken as an inspiration
from which both metamodels survive and compete. The influencing
relation might be explicit, i.e. stated by the creator in the original
proposal, or implicit, i.e. assumed or implied by a third-party source.
The evolutive relation is visualized by a directed line toward the
influenced metamodel. An explicit influence is symbolized with a solid
line, while the implicit with a dashed line. In both cases, the evolutive
relationship suggests an intersection of concept coverage, another form of
characteristic similarity.
OMG
UML v1(1997)
OMG
UML v2(2005)
OMG
SysML(2006)
OMG
SoaML(2009)
OpenGroup
Archimate(2006)
Business
SoaML(2012)
ServML(2013)
OMG
CMMN(2009)
OMG
VDML(2015)
BMC(2010)
s-BMC(2014)
Flow-
chart(1947)
ARIS
EPC(1992)
Rummler-
Brache
(1990)
ADF(2000s)
PCN(2012)
SBP(1984)
WebML(1998)
OMG
IFML(2015)
KPI
TDM(2009)
OMG
DMN(2015)
OMG
BPMN v1(2004)
OMG
BPMN v2(2011)
OMG
BPDM(2008)
Value
Network(2002)
e3 Value(2001)
REA(2005)
Capab
Map
(2011)
Value
Stream(1998)
BMI
Cube(2013)
POA(2016)
OMG
BMM(2008)
OMG
SBVR(2008)
OMG
ODM(2009)
SOFTWARE
PROCESS
VALUE
GOAL
DECISION
ONTO-
LOGY
SoBM(2017)
SDBM(2014)
CJM(1999)
PetriNet(1962) YAWL
(2002)
Euler’s
Graph(1736)
OMT(1991)
OOSE(1992)
Booch(1994)
State-
charts(1997)
ERD(1976)
DFD(1974)
Structure
Chart(1974)
PHYSICAL
WORK-
FLOW
SERVICE
INTERACTION
IBM
CBM(2005)
CAPABILITY
SJML(2013)
i*(1995) GRL
(2003)Ontology
LanguagesOWL, RDF,
CL, TM
UEML(2002)
ENTERPRISE
AG Soft
ARIS(1994)
KAOS(1993)
MEMO(2011)GoalML
(2014)
RULE
BMM-IT+(2013)
E-BMM(2009)
MODEL
136
The third relationship, compatibility, is taken from a conception that
a pair of metamodels is compatible and complementary. This claim can be
identified from the metamodel’s original source or from a separate
proposition. A compatibility relation is visualized by a thick shaded line.
A compatibility relationship infers a degree of distinction between the
pair of metamodels.
5.1.6 Metamodel Grouping
Positioning the metamodels based on its codes and relations provides an
opportunity to group the metamodels based on its similarity. An insight
for metamodel grouping emerges from correlating the tabular and
graphical presentation, as presented in figure 5.5. From this insight,
seven metamodel stereotype groups are defined. Each group is named
according to the dominant code in the group: (1) goal, (2) enterprise, (3)
business model, (4) service, (5) process, (6) software, and (7) system.
Group 1: Goal Metamodels
The group is characterized by emphasize on the concept of “business
goals”. Some of the group metamodel (e.g. KAOS, i*, GRL, GoalML) were
proposed within the context of requirement engineering activity during a
specific software engineering project. But since these metamodels
departed from the business goals and their distribution within the
organisational structure, they fall into an “enterprise” scope and “goal”
group.
137
OM
G
UM
L v
1(1
99
7)
OM
G
UM
L v
2(2
00
5)
OM
G
SysM
L(2
00
6)
OM
G
So
aM
L(2
00
9)
Op
en
Gro
up
Arc
him
ate
(20
06
)
Bu
sin
ess
So
aM
L(2
01
2)
Se
rvM
L(2
01
3)
OM
G
CM
MN
(20
09
)
OM
G
VD
ML
(20
15
)
BM
C(2
01
0)s
-BM
C(2
01
4)
Flo
w-
ch
art
(19
47
)
AR
IS
EP
C(1
99
2)
Ru
mm
ler-
Bra
ch
e
(19
90
)
AD
F(2
00
0s)
PC
N(2
01
2)
SB
P(1
98
4)
We
bM
L(1
99
8)
OM
G
IFM
L(2
01
5)
KP
I
TD
M(2
00
9)
OM
G
DM
N(2
01
5)
OM
G
BP
MN
v1
(20
04
)
OM
G
BP
MN
v2
(20
11
)
OM
G
BP
DM
(20
08
)
Va
lue
Ne
two
rk(2
00
2)e
3 V
alu
e(2
00
1)
RE
A(2
00
5)
Ca
pa
b
Ma
p
(20
11
) Va
lue
Str
ea
m(1
99
8)
BM
I
Cu
be
(20
13)
PO
A(2
01
6)
OM
G
BM
M(2
00
8)
OM
G
SB
VR
(20
08
)
OM
G
OD
M(2
00
9)
SO
FT
WA
RE
PR
OC
ES
S
VA
LU
E
GO
AL
DE
CIS
ION
ON
TO
-
LO
GY
So
BM
(20
17
)S
DB
M(2
01
4)
CJM
(19
99
)
Pe
triN
et
(19
62
)Y
AW
L(2
00
2)
Euler’s
Gra
ph
(17
36
)
OM
T(1
99
1) OO
SE
(19
92
)Bo
och
(19
94
)
Sta
te-
ch
art
s(1
99
7)
ER
D(1
97
6)
DF
D(1
97
4)
Str
uctu
re
Ch
art
(19
74
)
PH
YS
ICA
L
WO
RK
-
FL
OW
SE
RV
ICE
INT
ER
AC
TIO
N
IBM
CB
M(2
00
5)
CA
PA
BIL
ITY
SJM
L(2
01
3)
i*(1
99
5)
GR
L(2
00
3)
On
tolo
gy
La
ng
ua
ge
sO
WL
, R
DF
,
CL
, T
M
UE
ML
(20
02)
EN
TE
RP
RIS
E
AG
So
ft
AR
IS(1
99
4)
KA
OS
(19
93
)ME
MO
(20
11)
Go
alM
L(2
01
4)
RU
LE
BM
M-I
T+
(20
13
)
E-B
MM
(20
09)
1
12
2 3 4 5 6 7
3
4
5
6
MO
DE
L
N
ame
Cu
rato
r Y
ear
Sco
pe
Key
wo
rds
1 G
oalM
L (G
oal M
odel
ling
Lang
uage
) -
2014
E
nter
pris
e*
goal
, act
or, s
truc
ture
2
ME
MO
(Mul
ti-pe
rspe
ctiv
e E
nter
pris
e M
od)
- 20
11
Ent
erpr
ise*
go
al, p
roce
ss, o
rgan
izat
ion
3 K
AO
S (K
now
l. A
cqui
sitio
n in
Aut
omat
ed S
pec.
) -
1991
E
nter
pris
e go
al, s
truc
ture
4
GR
L (G
oal O
rient
ed R
equi
rem
ent
Lang
.)
ITU
-T
2003
E
nter
pris
e go
al, s
truc
ture
, dis
trib
utio
n 5
i* (
Dis
trib
uted
Int
entio
nalit
y)
- 19
95
Ent
erpr
ise
goal
, str
uctu
re, d
istr
ibut
ion
6 U
EM
L (U
nifie
d E
nter
pris
e M
od.
Lang
.)
Inte
rop-
NoE
20
02
(200
6)
Ent
erpr
ise
goal
, str
uctu
re, o
ntol
ogy
7 O
DM
(O
ntol
ogy
Def
initi
on M
etam
odel
) O
MG
20
09
(201
4)
Ent
erpr
ise*
on
tolo
gy, c
once
pt, r
ule
8
AR
IS (A
rchi
tect
ure
of I
nteg
rate
d In
fo.
Sys
t.)
AG
Sof
t 19
94
Ent
erpr
ise*
or
gani
zatio
n, p
roce
ss, p
rodu
ct
9 S
oaM
L (S
ervi
ce o
rient
ed a
rchi
t. M
od.
Lang
.)
OM
G
2009
(2
012)
E
nter
pris
e*
serv
ice,
arc
hite
ctur
e 10
S
OM
F (S
ervi
ce O
rient
ed M
odel
ing
Fra
mew
ork)
M
eth.
Cor
p.
2008
E
nter
pris
e*
serv
ice,
arc
hite
ctur
e 11
A
rchi
mat
e (A
rchi
tect
ure
of In
tegr
ated
Inf
o. S
yst.
) O
pen
Gro
up
2009
E
nter
pris
e*
stra
tegy
, bus
ines
s, a
ppl
icat
ion
12
E-B
MM
(Ent
erpr
ise
BM
M)
- 20
09
Ent
erpr
ise
stra
tegy
, bus
ines
s, a
pplic
atio
n 13
B
MM
-IT
+ (B
usin
ess
Mot
ivat
ion
Mod
el e
xten
sion
) -
2013
E
nter
pris
e st
rate
gy, s
truc
ture
, alig
nmen
t 14
B
MM
(Bus
ines
s M
otiv
atio
n M
odel
) O
MG
20
08
(201
5)
Bus
ines
s st
rate
gy, g
oal,
influ
ence
r 15
b-
SO
AM
L (B
usin
ess
SO
AM
L)
- 20
12
Bus
ines
s ar
chite
ctur
e, s
ervi
ce
16
BM
I Cub
e (B
usin
ess
Mod
el C
ube)
N
EF
FIC
S
2013
B
usin
ess
mod
el, i
nnov
atio
n 17
B
MC
(Bus
ines
s M
odel
Can
vas)
-
2010
B
usin
ess
mod
el, i
nnov
atio
n 18
S
-BM
C (S
ervi
ce B
usin
ess
Mod
el C
anva
s)
- 20
14
Bus
ines
s m
odel
, inn
ovat
ion,
ser
vice
19
S
oBM
(Ser
vice
Orie
nted
Bus
ines
s M
odel
ing)
-
2017
B
usin
ess
mod
el, i
nnov
atio
n, s
ervi
ce
20
SD
BM
(Ser
vice
Dom
inan
t B
usin
ess
Mod
el)
- 20
14
Bus
ines
s m
odel
, inn
ovat
ion,
ser
vice
21
C
BM
(Com
pone
nt B
usin
ess
Mod
el)
IBM
20
05
Bus
ines
s ca
pabi
lity,
str
uctu
re
22
CM
(Cap
abili
ty M
ap)
- 20
11
Bus
ines
s ca
pabi
lity,
str
uctu
re
23
VD
ML
(Val
ue D
efin
ition
Mod
elin
g La
ng)
OM
G
2015
B
usin
ess*
va
lue,
cap
abili
ty
24
e3-v
alue
(Eco
nom
ic e
-Com
mer
ce V
alue
)
2001
B
usin
ess
valu
e, e
xcha
nge
25
Val
ue n
et
- 20
02
Bus
ines
s va
lue,
flow
26
S
ervi
ceM
L (S
ervi
ce M
odel
ling
Lang
.)
SIN
TE
F
2013
B
usin
ess*
se
rvic
e, g
oals
, int
erac
tion
28
SJM
L (S
ervi
ce J
ourn
ey M
odel
ling
Lang
.)
SIN
TE
F
2013
(2
015)
B
usin
ess
serv
ice,
inte
ract
ion,
cus
tom
er
29
CJM
(Cus
tom
er J
ourn
ey M
ap)
IDE
O
1999
(2
014)
B
usin
ess
serv
ice,
inte
ract
ion,
cus
tom
er
30
PC
N (P
roce
ss C
hain
Net
wor
k)
- 20
12
Bus
ines
s se
rvic
e, in
tera
ctio
n, v
alue
31
S
BP
(Ser
vice
Blu
epri
nt)
- 19
84
(200
8)
Bus
ines
s se
rvic
e, p
roce
ss, i
nter
actio
n 32
P
OA
(Pos
sesi
on-O
wne
rshi
p-A
vaila
bilit
y)
- 20
15
Bus
ines
s pr
oces
s, v
alue
, exc
hang
e 33
V
alue
str
eam
-
1998
B
usin
ess
proc
ess,
val
ue
34
SB
VR
(Sem
antic
s of
Bus
ines
s V
ocab
. &
Rul
es)
OM
G
2008
(2
017)
B
usin
ess
onto
logy
, rul
e 35
T
DM
(T
he D
ecis
ion
Mod
el)
KP
I 20
09
Bus
ines
s de
cisi
on, r
ule
36
DM
N (D
ecis
ion
Mod
el a
nd N
otat
ion)
O
MG
20
15
(201
6)
Bus
ines
s de
cisi
on, r
ule
37
CM
MN
(Cas
e M
anag
emen
t M
odel
and
Not
atio
n)
OM
G
2009
(2
014)
B
usin
ess
case
, str
uctu
re, s
tate
38
B
PD
M (B
usin
ess
Pro
cess
Def
. Met
amod
el)
OM
G
2008
B
usin
ess
proc
ess,
col
labo
ratio
n 40
B
PM
N (B
usin
ess
Pro
cess
Mod
elin
g N
otat
ion)
O
MG
, IS
O
2004
(2
011)
B
usin
ess
proc
ess,
flow
41
E
PC
(Eve
nt P
roce
ss C
hain
) A
G S
oft
1992
B
usin
ess
proc
ess,
flow
, str
uctu
re
42
RE
A (R
esou
rce-
Eve
nt-A
gent
) -
1982
B
usin
ess
proc
ess,
str
uctu
re, o
ntol
ogy
43
UM
L (U
nifie
d M
odel
ing
Lang
) O
MG
, IS
O
1997
(20
15)
Sof
twar
e*
obje
ct, f
unct
ion,
beh
avio
r 44
Y
AW
L (Y
et A
noth
er W
orkf
low
Lan
g.)
YA
WL
Fou
nd.
2002
(2
013)
S
oftw
are
proc
ess,
flow
45
D
FD
(Dat
a F
low
Dia
gram
) -
1974
S
oftw
are
proc
ess,
flow
, dat
a 46
IF
ML
(Int
erac
tion
Flo
w M
odel
ing
Lang
.)
OM
G
2015
S
oftw
are
inte
rfac
e, fl
ow,u
ser
47
SC
(Str
uctu
red
Cha
rt)
- 19
88
Sof
twar
e flo
w, s
truc
ture
48
E
RD
(Ent
ity R
elat
ions
hip
Dia
gr)
- 19
76
Sof
twar
e da
ta, s
truc
ture
, ont
olog
y 49
S
ysM
L (S
yste
ms
Mod
ellin
g La
ng)
OM
G, I
SO
20
06
(201
7)
Sys
tem
* bl
ock,
func
tiona
l 50
ID
EF
(Int
egra
tion
Def
initi
on)
KB
SI
1995
S
yste
m*
func
tion,
dat
a, p
roce
ss
51
Flo
wch
art
AS
ME
19
47
Sys
tem
pr
oces
s, fl
ow
52
Sta
tech
art
- 19
87
Sys
tem
st
ate,
tran
sitio
n 53
P
etri
net
- 19
62
Gen
eral
flo
w, q
ueue
Fig
ure
5.5
: M
eta
mod
el
Gro
up
pin
g
138
The group is dominated by metamodels produced from the IT
discipline departing from software requirement engineering, as
exemplified by the pair of prospective dominating metamodels: GoalML
and MEMO. MEMO is quite popular and still evolving in collecting other
metamodels, including GoalML. MEMO is actually a metamodel proposed
with an “enterprise” context in mind. Its strong emphasize on the “goal”
concept puts it in this group. This actually illustrates an important
relationship between enterprise modelling and goal modelling.
Group 2: Enterprise Metamodels
This group is the first among three that takes its label from its coded
“scope”. Despite the claim that the enterprise engineering field is an
amalgamation of information science and organization science [163], the
group is largely dominated by products from the first academic discipline.
In a moderate pace, the group is quite prolific in producing metamodels.
More enterprise metamodel specifications can be expected from
competing frameworks, such as CIMOSA, GERAM, ISO-19439 and
DEMO[164].
The group is characterized by its wide coverage, traversing both
business and technical (software) aspect of an organization. While not
always detailed, it can encompass multitude of aspects, to include
potentially all other aspects within the modelling continuum. Due to this,
the group tends to produce ‘big’ metamodels, with a vast library of
notations and views.
139
Some enterprise metamodels exclude (goal) motivational aspects,
e.g. ARIS, the original Archimate), while others include them (e.g. UEML,
Archimate version 2.1 onward). The group also includes the service-
oriented metamodels, i.e. SOMF and SoaML, with a limited popularity.
Probably due to the coverage option range, the group still lacks a
dominant metamodel. So far, OMG has not published a specification for
this specific group. UEML was proposed academically to address the
“Tower of Babel” situation in the metamodel offering[165]. But its
development seems to have subsided in the last decade, only to be
eclipsed by newer offerings such as MEMO. Archimate, which is based on
the Open Group’s TOGAF framework, actually demonstrates a robust
quality, but it is still not academically popular enough to be regarded as a
dominant enterprise metamodel.
Group 3: Business Model Metamodels
This specific group is characterized by its attempt to convey a structure of
“money-earning logic”. It typically covers customer segmentation, market
positioning, product innovation, and relates to the internal supporting
structure. Due to this fact, the metamodels proposed in this group were
originally produced from non-computer science disciplines, i.e., business,
marketing and management disciplines. OMG also contributed a partial
coverage on this group with BMM specification, emphasizing on the
organizational motivation aspect, including the “goal” aspect.
140
Despite its specificity, the group can be considered to be dynamic.
The dominant metamodel BMC becomes the basis for many other
metamodel propositions. A re-factoring of BMC was proposed as BMI-
Cube. A new perspective from service-orientation extends BMC into s-
BMC, SDBM and SOBM, which respectively: (1) Elaborates the
component of customer and partner, (2) considers multiple parties
involvement and (3) adds a service repository concept.
The group also covers a minor theme of business “capability” and its
structure as exemplified by CM (Capability Map) and CBM (Component
Business Model). The concept of “capability” itself is linked to the concept
of “value”, “service” and “process”. With this fact, the group is expanding
and linked with contribution from other domain disciplines, including
service science and enterprise engineering.
Group 4: Service Metamodel
As the most fluid group, service metamodels stereotype actually a loose
confederation of several concepts coverage, i.e. “value”, “interaction”, and
“service”. The non-technical side is covered by the concept of “value-
exchange” or “value-interaction”, which is linked with the “business
model” group. In the technical side the concepts are linked to the
“software-service” as in SOA approach.
The concept of “interaction” is covered from several perspectives.
Interaction in the sense of “value-network” or “value-exchange” is
depicted by value-network metamodels (e.g. e3-value). The interaction can
141
also be conducted in inter-organization level, (e.g., B-SoaML), in customer
level (e.g., Service Blueprinting, CJM, SJML), or both (e.g., ServiceML,
PCN).
The contribution to the group is shared between the non-technical
domain of Service Science (e.g., Service Blueprint) and Service Operation
(e.g., PCN) and the technical domain, such as enterprise engineering (e.g.,
B-SoaML). This group can thus be considered as another integrative
concept as in “enterprise”, but from a specific perspective of a “service”.
As a relatively recent metamodel, VDML specification was
envisaged as an integrative metamodel which cover both the concept of
“value” and “capability”. From its introduction by OMG in 2015, it can be
expected to become a future dominant metamodel, potentially eclipsing
other “value” and “capability” related metamodels. But VDML lack of
detailed customer level “interaction” coverage, as abstracted in Service
Blueprinting, PCN, CJM, and SJML, makes it incomplete to cover the
whole “service” group. From the OMG perspective, the concepts covered
by these customer level interactions might be alternatively produced from
“process” modelling, i.e. BPMN.
Group 5: Process Metamodels
This group is characterized by the concept of a “process” which involved
both the terms “activity” and “workflow”. The group shares its origin from
both computer science and management science [166]. REA is an example
of proposition from non-computer related disciplines, i.e. accounting, with
142
an added “ontology” perspective. EPC is one example of offering from
computer science discipline. As one the oldest group in the structure, the
group therefore holds a vast library of metamodel offerings.
The introduction of BPMN by OMG in 2004 stabilizes the dynamic
aspect of the group which leads to the establishment of BPMN as the
dominant standard for “process” modelling. An attempt by OMG to
formalize and extend BPMN with BPDM proved to be unpopular which
led to the folding of the BPDM concept into the next iterative version of
BPMN. Later, a variant of process modelling was also introduced by OMG
in the form of CMMN for a specific type of consultative process, i.e.,
“case”, which typically involves knowledge workers. Other specific
variants of process modelling were also introduced by OMG to structuring
a decision process as DMN. These last two metamodels highlight
additional aspects covered by this group: “decision”, “rule” and “ontology”.
The three OMG’s process model (BPMN, CMMN and DMN) are actually
envisioned to complement each other during process modelling.
The “process” model can be viewed as the core element in the global
continuum of the modelling concept. It is upward linked with goal,
enterprise, service and business models, and downward linked to
software models. This notion can also be observed from the fact that,
BPMN is demonstrated to have a compatibility relationship with all other
OMG metamodels.
143
Group 6: Software Metamodels
As the second stereotyped group named after its scope, the group has
specific context in modelling a “software” system. The contributing
domains are therefore specific from computer science and software
engineering disciplines. With its long tradition of modelling, the domains
evolved its engineering approach in a certain pace, along with
introduction of improved set of specific modelling technique. Combining
the factors of historical evolution and the multitude of software aspect,
the group possess a myriad of metamodel options. The arrival of UML in
the late 90’s altered this landscape.
While other older metamodels may still survive, UML has become
the de-facto metamodel in Software Engineering. While its adoption in
the industry might be debatable [167], UML offers two advantages over
other metamodels. First, UML is formalized into a metamodel
architecture by having a meta-metamodel parent: Meta-Object Facility
(MOF), to which other OMG’s metamodels are aligned. This way, UML is
theoretically convertible to any other metamodel based on OMG’s MOF.
Secondly, UML is extendable, that is a new metamodel can be created
based on it for a specific purpose by defining an UML profile. Some
examples of this are the SoaML and SysML. While not formally stated,
Archimate can also be observed to possess notational likeness with UML.
144
Group 7: System Metamodels
The last group also takes its name from the scope: “system”. The group
holds together the older class of metamodels and often serves as the
source of influence to other newer metamodels. The group consists of a
general purpose metamodel commonly use to describe a system, in a
generic context, often as a physical or a complex system [115].
Categorized within this group, IDEF is actually a family of
metamodels, originally envisioned to range from IDEF0 to IDEF14, in
covering enterprise wide concepts such as data, process, business and
network. In its implementation only several of them are fully developed
[168]. Despite its adoption by IEEE in 1999, IDEF has a very limited
adoption beyond its original intended usage within United States
Department of Defense (DoD).
The group can also be considered stable after the introduction of
SysML by OMG. Based on International Council on Systems Engineering
(INCOSE) proposal, SysML extends UML by simplifying and modifying it
into seven types of diagram and introducing two new diagrams to produce
a metamodel for physical system, e.g. machinery or aircraft.
It is worth to note that the boundary between these stereotyped
groups is not a clear-cut line. Due to often interlinked concept coverage in
each group, a metamodel can potentially be categorized to belong to two
or more groups. Nevertheless, the proposed grouping structure produces
145
an identification of important concepts covered by each group and the
relationship between the groups and the concepts.
5.1.7 Metamodel Proliferation Pattern
From these results, three evolutive patterns of metamodel
proliferation can be observed. The first pattern is the introduction of an
entirely new metamodel, on previously unchartered area or taking a
unique perspective on modelling the underlying object, with relatively
minimal influence from previously available metamodels. Examples of
these pioneering metamodels are: Flowchart (1947), Service Blueprinting
(1984), i* (1995), REA (2005), TDM (2009) and BMC (2010). The BMM
(2008) is a rare example of original metamodel proposed by OMG. In a
lesser degree, OMG’s SBVR (2008) can also be seen as an original
metamodel, but two facts diminish its originality: It was built based on
the MOF specification, and it has some influences from declarative
languages (i.e., CL and OWL). These pioneering metamodels could also be
seen as a departure point, upon which a group of similar metamodels
flourished.
The second pattern is the introduction of a new metamodel which is
explicitly based or implicitly inspired from previously available
metamodels. The recent metamodel proliferation is due to metamodels
produced based on this pattern. The new proposition can take the same
name of the original metamodel, with version number, or with an entirely
146
new name. There are at least three motives underlying the introduction:
(1) improving the detail quality, (2) enlarging the coverage, and (3)
adapting to a specific context.
The evolution of Service Blueprinting (1984, 1987, 2006, 2011)
toward PCN (2012) is an example of the first motive. The second motive
can be exemplified by the introduction of E-BMM (2009) after BMM
(2008), and by evolution of Archimate (2006) toward strategic and
motivational aspects in its third version (2016). The third motive can be
illustrated by “service” derivation of BMC (2010) into SDBM (2014), S-
BMC (2014) and SoBM (2017), and the specific business level adaptation
of SoaML (2009) into b-SoaML (2012).
The third pattern is the integrative attempt in which different
metamodels are formally collected to become a family. This pattern can be
typically observed from OMG metamodels, e.g., UML (1997), BPMN
(2004), ODM (2009), and VDML (2015). The integrative attempt can
either adapt the source metamodel as it is (e.g., ODM), or add some
modifications (e.g., VDML) to allow a better compatibility between its
components. The pattern can also be seen outside of OMG metamodels,
such as ServML (2012) in service modelling, UEML (2002) and MEMO
(2011) initiatives in enterprise modelling.
These patterns illustrate the importance of visibility for a
metamodel to be considered as a significant contribution to the
competitive landscape of metamodel offering. For obvious reason, the
early-pioneering metamodel has a better chance to become a significant
147
metamodel. But a lack of a continuous supporting interest could also
make a metamodel irrelevant and obsolete. A certain level of academic
discussion and, most importantly, industrial adoption are required for its
survival. An adoption by an authoritative curator body (e.g., OMG, ISO)
is an important factor in overseeing metamodel usage beyond its initial
inception.
5.1.8 Discussion on Metamodel Landscape Structure
Some limitations are observed from the metamodel exploration
results. First is the missing occurrence of supporting information system
components, such as the abstraction of software modular structure (e.g.,
software service, software component), computing node (e.g. physical or
virtualized server) and its connectivity pattern (e.g., network). A
justification can be made that these components only become important
in later stages of the design phase, toward implementation modelling.
Nevertheless, these components could still be considered as important
concepts due to the fact that these concepts are actually covered by some
metamodels in software and enterprise modelling. To bring out these
concepts, a more refined coding approach, toward individual diagrams
level of a metamodel family (e.g. UML), is required. This refined approach
is decidedly out-of-scope for this research.
The second limitation is observed from the odd recurrence of
“ontology” in the structure. Ontology is mentioned in the three scopes:
148
software, business, and enterprise contexts. This suggests that the
concept of “ontology” persists in multiple contexts. This notion is
supported by both Zachman [116] and TOGAF [117] enterprise
architecture framework. In this case, confronting the emerged results
with a predefined formal structure could be considered for further
improvement of the result. A richer structure might also emerge from
analysing the metamodels in its individual diagram level.
5.2 Service Engineering Ontology and Artefact
To verify the completeness of framework coverage on the aspects of
service system, a comparative triangulation is made between the
produced service ontology with artefacts defined in the framework. This
cross-referencing into the proposed metamodels also serves as a bridge to
characterize the artefacts form.
The assessment is performed in four parts divided by sub-stage, i.e.
activity, from the latest iteration of proposed framework (figure 5.6) : (1)
Understanding Service Context, coded as activity 1, (2) Defining Service
Concept, coded as activity 2, (3) Business Service Design, coded as
activity 3, and (4) Software Service Design, coded as activity 4.
149
2.2 Software Service
System Design
2. DESIGN
2.1 Service
Design
2.1.2
Interaction
Model
2.1.3
Process
Model
2.1.4
Business Information
Model
2.1.1
Service
Architecture
Model
2.2.1
Atomic
Service
2.2.2
Composite
Service
2.2.4
Service
Detail
Model
2.2.3
Service Information
Model
1.2.1
Business
Modeling
(to-be)
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Service Context
Understanding
1.2 Service Concept
Definition
1.2.3
Business
Service
(to-be)
1.1.3
Business
Process
(as-is)
1.1.5
Opportunity
Priority
1.1.2
Business
Model
(as-is)
1.1.4
Business
Capabilities
1.2.2
Service
Goal & Value
(to-be)
Activity
Artifact
Stage
Activity 1 Activity 2 Activity 3 Activity 4
Figure 5.6: Service Engineering Framework Structure (3rd iteration)
5.2.1 Artefacts in Activity 1 (Understanding Service Context)
Before proposing new or improved services, an understanding
toward the context is required. The activity in the first part of the
identification stage captures and analyses the existing situation of the
environment.
The activity covers foundational aspects of an organization. As
illustrated in figure 5.7, four existing-situation aspects are captured as
artefacts in this sub-stage: (1) business directives, (2) business model, (3)
business process, and (4) business capability. The framework proposes to
capture the guiding business directives as a list of narratives, which can
be presented in tabular format. The current business model is visualized
with BMC while the business process with BPMN.
150
1.1.5
Opportunity
Priority
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Understanding Service Context
1.1.3
Business
Process
(as-is)
1.1.2
Business
Model
(as-is)
1.1.4
Business
Capabilities
Entity
BoundaryService
Interface(Interaction Point)
Operation
Message
Entity
Business
Model
Process
Rule
Collaboration
Role
Choreograpy(Contract/Protocol)
Capability Value
use
Use
has
sequence
hasProcess
Task
(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
govern
has
Motivation
has
drive
has
refer
Part
of
use
1
2
3
4
5 6
7
3a
3b
3c 4a
4c
4b
7a
7b
7c
7d
Business
Model
Canvas
BPMN
Business
Process
Component
Business
Model
Business
Goals
Existing
ArtefactsFormat/
MetamodelOntology Components
Figure 5.7: Artefact Ontological Position in (Activity 1.1)
The currently owned and potentially owned capabilities of the
organization are also examined and presented in a capability diagram.
The analysis and modelling could be based on Component Business Model
(CBM), which is based on organization structure, or based on SoaML
capability diagram.
The result of this sub-stage should be an identification of
opportunities to be pursued in provisioning a business service. The
opportunity could be numerous. Therefore, a ranked list should be made
based on combination of various factors such as feasibility, prospective
gain and cost, or resources required.
In identifying the opportunity, external perspectives must also be
incorporated. These external perspectives should capture the market
opportunity and business partnership. In the framework, the combination
of outward and inward-looking perspective is accommodated in the last
151
artefact, the opportunity list. The framework does not specify the
standard format for the list, but it is usually in a narrative format
produced from business analysis techniques, such as a SWOT or Value
Chain Analysis. Any format should be acceptable as long as it helps the
management to decide a specific opportunity to pursue.
5.2.2 Artefacts in Activity 2 (Defining Service Concept)
The second part of the identification stage is a business-side
elaboration of the selection decisions made in the first part. The activity
produces a high-level view of the service to be design and implemented.
Entity
BoundaryService
Interface(Interaction Point)
Operation
Message
Entity
Business
Model
Process
Rule
Collaboration
Role
Choreograpy(Contract/Protocol)
Capability Value
use
Use
has
sequence
hasProcess
Task
(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
govern
has
Motivation
has
drive
has
refer
Part
of
use
1
2
3
4
5 6
7
3a
3b
3c 4a
4c
4b
7a
7b
7c
7d
1.2.1
Business
Modeling
(to-be)
1. IDENTIFICATION
1.2 Defining Service Concept
1.2.3
Business
Service
(to-be)
1.2.2
Service
Goal & Value
(to-be)
To-Be
Business
Model Canvas
Service
Goal
Business
Service
Catalog
Figure 5.8: Artefact Ontological Position in (Activity 1.2)
Figure 5.8 shows three (to-be) aspects to be covered: (1) Business
Model, (2) Service Values and Goals, and (3) Business Service definition.
The targeted business model is formalized as an artefact configuring the
business concepts in terms of the BMC components, e.g. partnership,
supporting activities, customer segment, channel, and others.
152
The service goal and value elaborate the value components of BMC
by declaring the objectives and proposed values of targeted service, as
directives in identifying service features and designing service processes.
The format for service goals and value artefact should be a simple
numbered table listing the objectives and values.
The final artefact of this sub-stage is a business service catalogue.
This artefact is simply a formal catalogue of business services to be
provided, in term of roles provided in the service with specific service
features derived from service objectives and values. The table
presentation of the artefacts could be combined with the list of service
objectives and values to provide traceability between the service goals
and features.
5.2.3 Artefacts in Activity 3 (Business Service Design)
The third activity delves into the design stage by detailing the
mandates set by the previous stage. Four business-service aspects are
covered, as described in figure 5.9: (1) Service Architecture, (2) Service
Interaction, (3) Service Process, and (4) Business Ontology.
153
Entity
BoundaryService
Interface(Interaction Point)
Operation
Message
Entity
Business
Model
Process
Rule
Collaboration
Role
Choreograpy(Contract/Protocol)
Capability Value
use
Use
has
sequence
hasProcess
Task
(Atomic)
Activity(Composite)
use
has exchange
exchange
perform
has
Motivation
has
drive
has
refer
Part
of
use
1
2
3
4
5 6
7
3a
3b
3c
4a
4c
4b
7a
7b
7c
7d
2. DESIGN
2.1 Business Service
2.1.2
Interaction
Model
2.1.3
Process
Model
2.1.4
Business Information
Model
2.1.1
Service
Architecture
Model
SoaML
Service
Archit.
BPMN
Business
Process
SoaML
Service
Contract.
Service
Blueprint
govern
Data Asset
has
use
UML Class
Diagram
Figure 5.9: Artefact Ontological Position in (Activity 2.1)
Service architecture visualizes a global collaboration relation
between participants of the service community. The pairing roles of
provider and consumer are a basic form of the architecture, but the
relation might be connected with multiple service options. The artefact is
particularly important for a service system which involves more than two
parties or roles within the service scope. SoaML service participant
diagram format is ideal to present this artefact, by relating the
component of: participants, roles, and services.
Service interaction artefacts specify the touch point between a
consumer and the providing participants throughout the cycle of service
provision. The model focuses on the description of the process flow
performed by consuming parties. The specification covers type of channel,
interfacing mode, and specification of resource exchanged, e.g. document
or information. Service Blueprinting (SBp) technique is suggested as a
format for this artefact. Interaction rules, e.g. operational hours, pre-
154
requisite service states can be specified in the form of SoaML service
contract, accompanying a SoaML service architecture.
The process model specifies the flow of activities, mostly in providing
participants, covering through its collaboration with the co-providers.
Special attention is given to the atomic abstraction of the activity tasks
with interactivity feature: service-operation. These operations are the
potential baseline for (software) service definition [77]. The artefacts are
formatted in the de-facto format of business process metamodels: BMPN.
The fourth artefact to be produced lies in the ontology engineering
context, in defining the business ontology model [53][82][10] as part of
(service) ‘product model’ [31]. The ontology artefact should cover ontology
components related to business models and service system, as a part of
the whole business domain ontology. The artefact can be presented in
UML class diagram.
5.2.4 Artefacts in Activity 4 (Software Service Design)
The fourth activity mirrors the activity in the ‘Business service design’
sub-stage. The difference is that the service elaborated in an IT context,
i.e. software context, rather than in a business context as in the previous
sub-stage. Figure 5.10 lists four aspects to be covered from the ontology at
the software-service level: (1) Atomic service, (2) Composite service, (3)
Service Detail, and (4) Service Information.
155
IT Ownership Boundary
Service Interface
Operation
Message
Software Element
(Entity)
Service
Contract
(Rule)
Software
Interaction
(Collaboration)
Role
Interaction
Protocol
(Choreography)
has
sequence
has
Software
Service
(Capability)
Atomic
Service
Composite
Service
exchange
has
Perform
(Provider/Consumer)
1
Port
(Interaction Point)
4b
has
Part
of
has
has
use
refer
use
4
3a
3b
3c
7
7a 7b
7d
4a
4c
use
7c
Software Service Level Analysis
5
2.2 Software Service
2. DESIGN
2.2.1
Atomic
Service
2.2.2
Composite
Service
2.2.4
Service
Detail
Model
2.2.3
Service Information
Model
SoaML
Interface
SoaML
Service
Interface
SoaML
Message
Type
UML
Behaviour
SoaML
Participant
SoaML
Service
Interface
Internal
Composite
Service
Externally
Dependent
Composite
Service
Figure 5.10: Artefact Ontological Position in (Activity 2.2)
The atomic service specifies the design of a self-sufficient software
service in terms of the service interface, contained operations and its
underlying behaviour. The artefact is presented as diagrams of SoaML
Interface.
The composite service describes the combined use of the atomic
service in the form SoaML Service Interface which includes the behaviour
in the form of a sequential arrangement of operations invocation. In the
case of a composite service, it contains invocations to external services,
i.e. services provided by other participants, the behaviour specification
represents a software level collaboration-interaction with an external
software component.
The service detail aspect gathers the software services into an
abstracted form of software components with a service port, invoked and
156
invokable services into a SoaML Participant. All service behaviours are to
be detailed in this container, to be implemented later as software
components. These components serve as a representation of an
interacting party, either as a consumer, as a provider or both.
Finally, the service information collects all of the information
exchanged between services as operands and return values of invoked
operations. SoaML message type diagram is defined for each service
interaction transaction and cross-referenced with business information
artefacts from previous activity to be standardized in maintaining
consistency while at the same time facilitate message type reusability.
In general, the described triangulation between ontology and
framework artefacts demonstrates a sufficiency of framework coverage in
assessing service aspects and components, both in business and software
perspective. In this stage, the prescribed metamodel of targeted artefacts
is an open specification. The suggested metamodels are demonstrated to
be sufficient for the case studies. But the dynamic nature of the
metamodel landscape may offer alternative formats that might be better
in capturing the modelling needs.
5.3 Alternative Service Engineering Metamodels
The first part of this chapter presents an emerging structure of a
metamodel landscape from a grounded approach. While a clear
differentiation between metamodel groups is not claimed, seven
157
stereotypes of metamodel are offered: (1) goal, (2) enterprise, (3) business
model, (4) service, (5) process, (6) software, and (7) system.
The “service” perspective emerges as an alternative integrative
approach, as in “enterprise” perspective, in traversing the context
between “business” and “software” aspects. The “service” perspective
covers the aspects of “business model”, “business capability”, “business
interaction”, “value proposition”, “value exchange”, “customer
interaction”, and “software service”, which is consistent with the produced
Service Engineering Framework.
The observed proliferation pattern of metamodel projects its nature
as an ever-dynamic landscape. Some cross-disciplinary initiatives might
pursue an integrative universal metamodel. But a more pragmatic and
feasible option is available in the form of specifying a metamodel stack
[65][62], such as adopted by the framework of this research. As a set of
originally unrelated metamodels, special care must be taken to ensure
the traceability and translatability of the artefacts between stage and
activity.
Examining the metamodel landscape, several newer metamodel
propositions are worthy to be proposed as metamodel alternatives. The
following section presents these potential metamodel alternatives divided
into four sub sections: (1) OMG’s Business Motivation Model (BMM)
[132], (2) OMG’s Value Definition Modelling Language (VDML) [138], (3)
alternative Business Modelling, and (4) alternative Interaction Modelling.
These alternatives are proposed here as potential options. For an actual
158
use, another set of case-study is required, which is beyond the scope of
this research iteration.
5.3.1 Business Motivation Model
As the name implied, Business Motivation Model (BMM) [132]
covers motivational aspects of a business case. It is situated on the
strategic level of a business model by defining the drivers, the element
and its interrelations for a business plan, without elaborating the
detailed aspects of business process and business structure.
<<Tactic>>
Hire a
construction
company
<<Tactic>>
Plan the
warehouse
rework
<<Strategy>>
Rework the
warehouse
<<Mission>>
Warehouse
reworked to
support delivery
<<Goal>>
Warehouse
rework complete
<<Vision>>
Warehouse
suited for
delivery
<<Means>> <<End>>
<<Internal Influencer>>
Warehouse needs rework to
support delivery
Category: Infrastructure
<<Assessment>>
Warehouse is not
suited for delivery
Category: Weakness
<<judge>>
<<affect
employment>>
<<ennable>>
<<imple-
ment>>
<<make
operative>>
<<channel
efforts>>
Figure 5.11: Sample of Business Motivation Model Artefact [169]
From the illustration in figure 5.11, BMM can be seen as an
ontological structure for business motivation, which relates to two
aspects: (1) Ends, defined as situations to be achieved, i.e. goals and
objective, and (2) Means, as concepts adopted to achieve the ends, i.e.
strategies, tactics, policies, and rules.
Not many published articles are found documenting BMM adoption
for real world cases, but the recent update to the specification introduces
metamodel notations for modelling purposes[169]. BMM metamodel can
159
be useful for structuring a business goal artefact in the framework. If
needed, BMM is useful to document the traceability between the
components of goals, objectives, strategies, tactics, policies, and rules, as
a directive context for a service system.
5.3.2 Value Definition Modelling Language
Value Definition Modelling Language (VDML) [138] is a relatively recent
metamodel to be introduced by OMG. It covers business concepts in terms
of activities, roles, flows, participants and capabilities in a higher
abstraction compared to BPMN. VDML is proposed as a modelling
language for business analysis with focus on value creation and exchange,
by combining external perspective on market opportunities with extended
organisational capability structure.
Like UML and SoaML, VDML is actually a family of diagrams,
which contains eight types of diagram: (1) Role Collaboration, (2) Value
Proposition Exchange, (3) Activity Network, (4) Collaboration Structure,
(5) Capability Library, (6) Capability Heat Map, (7) Capability
Management, and (8) Measurement Dependency. The detail specification
of these diagrams is out of scope for this chapter, but it suffices to identify
the components relevant to the framework, with comparison to existing
metamodels.
Role collaboration and Value proposition exchange describes service
architecture, as a network of providers and consumers, in term of
160
participant role and value (potentially) exchanged. For this purpose,
SoaML’s Service Architecture is decided to be sufficient to present the
similar abstraction, with a compact abstraction of participants, roles and
service interactions.
On the other hand, VDML is quite attractive to represent the
concept of capability in the framework. Among three of its capability
related diagrams, two are identified to have potential use in the
framework: (1) capability Library and (2) capability management.
1. Innovation
1.1
Idea
Submission
1.2
Innovation
Submission
1.3 Innovation Management
1.3.1
Idea
Submission
1.3.2
Engineering
1.3.3 Idea
Submission
1.3.3.1
Release
Planning
1.3.3.2
Market
Introduction
2. Acquisition
3. Acquisition
21
Product
Procurement
3.1
Product
Operation
4. Fulfillment
4.1 Fulfillment Management
4.1.1
Fulfillment Planning
4.1.2
Product Delivery
5. Production
4.1 Production Management
4.1.2
Product Excecution
Figure 5.12: Sample of VDML Capability Library [138]
As can be seen in figure 5.12, the capability library provides a
hierarchical structure of capabilities in an organization, which could be
useful to replace the use of a Component Business Model (CBM) in the
capability modelling in identification stage.
The capability management provides a graphical abstraction for
ownership, dependency and exposition of capability within an
organization or an extended organization (figure 5.13). It has similarity
161
with SoaML’s participant diagram in software-services but resides in the
‘capability’ context. VDML capability management diagram is also
identified to be a potential metamodel for a capability model artefact, as
it has the features to accommodate an extended organization and
business model.
Capability
Offer 1
Capability
Offer 2
Capability
Method
Entity 1
Capability
Offer 4
Capability
Offer 3
Entity 2
+ +
Realization Dependency
Figure 5.13: Sample VDML Capability Management [138]
5.3.3 Business Modelling
Business modelling is a growing research area which flourished since the
introduction of BMC in 2010. In the metamodel exploration, three
business modelling languages are identified to be potentially relevant for
the framework: (1) Service Dominant Business Model (SDBM) [136], (2)
Business Model Innovation Cube (BM Cube) [134], and (3) Service BMC
(S-BMC) [135].
SDBM offers a simple view of service business model with only four
components [136]: (1) Service as the core element, (2) Management,
representing the ‘how’ aspect of service access, analogous with
relationship and channel components in BMC, (3) Benefit-Cost,
162
characterize the service value for specific participant in mostly financial
context, and (4) Actor as providing or consuming participant of the
service. All of the components are visualized as layers circling a specific
service in the centre, as illustrated in figure 5.14.
Free
music listening
experience
Playlist
sharing
Music
library
Music
streaming
Playlist
sharing
Playlist
listening
Advertising
media
Free
access
Advertising
listening &
interuption
Advertising
RevenueSong
streaming
cost
Song
streaming
revenue
Advertising
distribution
cost
Service
Management
Benefit
Record label
Advertiser
Spotify
Free
customer
Unlimited
music listening
experience
Playlist
sharing
Music
library
Music
streaming
Playlist
sharing
Playlist
listeningAdvertising
free
Subscription
RevenueSong
streaming
cost
Song
streaming
revenue
Service
Management
Benefit
Record label Spotify
Paying
customer$5/month
Figure 5.14: Sample of Service Dominant Business Model (SDBM) [136]
SDBM strength lies in its simplicity in abstracting a service with
multiple participants. But compared to the standard BMC, SDBM lacks
the specification of activities and resources involved in the service
provision. Despite its limitation, SDBM is still an attractive format as an
early form of the service business model, describing a preliminary
architecture of service participants.
163
Cost Revenue
Activity
Resource
Partner Value
Relation
Channel
Client
Value Proposition
User & Customer
(Internal) Value
Chain
Competence
Network
Relation
Value Formula
Business
Model Canvas
(BMC)
Business Model
Innovation Cube
(BM Cube)
Figure 5.15: BM Cube components mapping with BMC [134]
BM Cube [134] is a reformulation of BMC in re-combining several of
the components into seven components, forming the sides and the centre
of a cube (figure 5.15), which are: (1) Value proposition, (2) user and
customer, (3) internal value chain, analogous with BMC’s channel and
activity, (4) competence, represents BMC’s resource, (5) networks, for
BMC’s partner and channel, (6) relation, as in BMC’s relationship, and
(7) value formula, combining BMC’s cost and revenue components.
The proposed cubical presentation has no practical benefit, but BM
Cube represents a trend toward an Open Business Model [134], which
features an explicit abstraction for an extended business network. The
offered simplification of BM Cube might be useful for some cases, but its
sufficiency for a real-world case still needs to be further examined.
Service BMC (S-BMC) is another reformulation of the BMC format
by extending its usage for multi-party business models. In S-BMC, seven
BMC components are spread vertically, and each participant’s
perspective are specified as layers of these component.
164
Three perspectives are offered in its basic format: (1) customer
perspective, (2) internal organization perspective, and (3) partner
perspective (figure 5.16). Additional layers might be added for other
business participant, as intermediaries either toward the customer or
partner side (figure 5.17).
Customer(Customers in the business model)
(Cost borne by
customers)
(Resources
provided by
customers)
(Activities
carried out by
customers)
(Value
proposition for
customers)
(Customers
contribution in
relationship)
(Channel
provided by
customers)
(Revenues
captured by
customers)
Cost Structure
(Cost borne by
local company)
Key Resources
(Resources
provided by
local company)
Key Activities
(Activities carried
out by the local
company)
Value Proposition
(Value proposed
by the local
company)
Relationship
(Contribution of
local company in
relationship)
Channels
(Channels
provided by the
local company)
Revenue Streams
(Revenues
captured by local
company)
(Cost borne by
partners)
(Resources
provided by
partners)
(Activities
carried out by
partners)
(Value
proposition for
partners)
(Partner
contribution in
relationship)
(Channel
provided by
partners)
(Revenues
captured by
partners)
Key Partner(Partners in the business model)
Cus
tom
er
pers
pect
ive
Com
pany
pers
pect
ive
Par
tner
pers
pect
ive
Figure 5.16: Structure of Service BMC (S-BMC)[135]
CUSTOMER
- Debit card
- Compatible
mobile device
- Setup cost &
operation (e.g.
staff,negotiation)
- Infrastructure
KEY PARTNER
Customer
Cost Structure Key Resources Key Activities Value Proposition Relationship Channels Revenue Streams
Customer:
- Differentiated Business-to-Consumer Segments
- Low number of transaction / Low or no willingness to pay
Merchant:
- Undifferentiated Business-to-Business Segments -
Low number of transaction / Low or no willingness to pay -
- Compatible
mobile device
- Right of debit
card disposal
- Registration
- Configuration
- Authentication
- Account mgt.
- Payment safety
- Payment speed
- Saving by m-
marketing.
- Registration
for automated
or self service
- Smartphone
with installed
mobile app
- Saving (e.g.
monetary and
time)
- Setup cost &
operation
- Infrastructure
(terminal etc.)
- System, terminal
- Right of merchant
account disposal
- Staff
- Configuration
- Awareness
- Confirmation
- Settlement.
- Payment safety
- Payment speed
- Cost saving
- Customer data
- Automated
or self service
- Personal store
assistant
- Web
- After sales
- Store
- Customer per
sale or
purchase
volume
- Payment infra-
structure, system
- Customer and
merchant basis
- Staff
- App developmnt,
& operation
- Transmission of
payment
- Increased
platform sales
- Operational
cost reduction
- Integrated into
service
provision
- Mobile payment
system
- Mobile app
- After sales serv.
- Flat fee
(membership)
- Transaction
fee (discount)
Payment Provider
(e.g. bank)
Technology Provider
(e.g. ISP)
- Setup cost &
operation
- Infrastructure
- Payment
Infrastructure
- Risk mgmt.
- Settlement
(direct debit)
- Sales increase
- Cost saving
- Automated
service
(settlement)
- Web
- Sales force
- Merchant usage
fee (transaction
based)
- Setup cost &
operation
- Infrastructure
- Checkout
system, plugin,
terminal
- Sales increase - Personal
assistance
(distribution)
- Sales force - Per sale from
merchant
Merchant
Company
Payment
provider
Technology
provider
Figure 5.17: Sample of S-BMC Artefact with five party layers [135]
It can be observed that the three alternatives business model
formats try to address BMC limitation in representing an extended
organization, as a service system formed by multiple participants. BMC
or BMI format is fairly sufficient for simple business cases with one
165
dominant providing participant. But to represent complex business model
architecture, SDBM or S-BMC might be required.
5.3.4 Interaction Modelling
Four interaction modelling formats are identified in metamodel
exploration: (1) Process Chain Network (PCN) [143], (2) Service Modelling
Language (Service ML) [141], (3) Service Journey Modelling Language
(SJML) [142], and (4) Customer Journey Map (CJM) [89].
PCN is proposed in service operation management field as an
attempt to improve Service Blueprinting (SBP) [143]. PCN focuses on the
touch point by introducing three degree of interaction layer for each
party, i.e. provider and consumer: (1) direct interaction, (2) surrogate
interaction, and (3) independent processing.
Seat
customer
Create
order
Wait to be
seated
Review
menu
Wait for
pizza
Eat
pizza
Serve
pizza
Present
bill
Provide
payment
Travel to
restaurant
Return
home
Eat
leftovers
Assemble
ingredients
Cook
pizza
Develop
recipes
Preheat
ovens
Maintain
supplies
Prepare
bill
Direct
interaction
Direct
interaction
Surrogate
interaction
Surrogate
interaction
Independent
processing
Independent
processing
Back-office
steps
Non-service
production
Front-office
stepsSelf-service Non-service
Restaurant’s Process Domain Customer’s Process Domain
Restaurant Customer
Service process steps
Figure 5.18: Sample of Process Chain Network (PCN) Artefact [143]
166
The presentation has similar feature with SBP by defining
participant activities in the interaction, but the elaboration is not only in
the provider side but also accommodated in the consumer side (figure
5.18). PCN presentation also provides an abstraction of business-process
networks, by aligning series of interactions for multiple service
participants (figure 5.19). In this sense, PCN can be seen as an
alternative improvement of SBP for multiple participants’ interaction,
without separate components for exchangedartefacts such as physical
evidence in SBP.
Discuss
symptoms
Prescribe
medication
Wait
Check-in
at kiosk
Drive to
pharmacy
Drive to
clinic
Feel
better
Take
medication
Call in
prescription
Submit
payment
claim
Clean lab
tools
DirDir.Sur. Sur IndInd
Health Clinic
Take
blood
Analyze
blood
Train staff
on tools
Procure
lab toolsFeel
weak
Show
ID
Give
payment
Patient
C
D
Submit
payment
claim
Check
coverageProcess
payment
Review
claim
DirDir.Sur. Sur IndInd
Insurance Company
Establish
medication
coverage
agreement
Pay
covered
amountCheck
ID
Tell copay
ammount
Pharmacy
C
D
B
A
Sur.Dir. Sur Dir
Fill pre-
scription
B
Sur Dir
Develop
payment
schedule
A
Sur.Dir.
Figure 5.19: Network of Interactions in PCN [143]
ServiceML [141] was proposed in a similar manner with VDML, as a
family of diagrams collecting representations of ‘service’ concepts. Five
types of diagram are defined, as summarized in figure 5.20:
167
1. Needs model, as a diagram relating customer needs with required
service features.
2. Service Architecture, as a simplification of SoaML’s Service
Architecture connecting participant and service (contract).
3. Actor Network, as a detailed version of Service Architecture with
participant role and individual flow of sequential interaction.
4. Service Journey Map (SJM), as a graphical representation of a
series of touch-points experienced by customer throughout the
cycle of service provision.
5. Service Experience Journey Map, a similar form of SJM with
colour-code representing expected customer (emotional) experience.
(a) Needs Model
(b) Service Architecture
(c) Actor Network
(d) Service Journey Map
(e) Service Experience Journey Map
Customer
needs
Service
Goals
(feature)
Participant
Service
contract
Roles
Deliverables
Participant
Touchpoints
Participant
Emotional
experiences
Figure 5.20: Diagramsin ServiceML [141]
168
Each of these diagrams has usage potential for the framework. The
needs model may be used to relate service goals (artefact 1.2.2) and
service features in business catalogue (artefact 1.2.3). Service
architecture simplification, which was also introduced as part of b-SoaML
[133], might replace SoaML’s format for artefact 2.1.1.The details of Actor
Network is more appropriate in the later stage, such as for accompanying
the Interaction model (artefact 2.1.2).
The actual interaction model is offered in the form of SJM. The
diagram focuses on the touch-points from the consumer side and a
suitable format for the interaction model (artefact 2.1.2). This interaction
model describes a ‘service path’ [23], as a series of service encounters
while at the same time reflect service states. The omission of supporting
back end activities avoids a coverage redundancy with the process model
(artefact 2.1.3).
Customer
phones the
call center
T1
Customer
receives
email with
deals and
prices info
@
T2
Sales
person
phones
customer
T3
Customer e-
mails service
provider and
indicates
wanted deal
@
T4
Customer
receives
email with
deals and
prices info
@
T5
Customer browses the
service provider’s web-
sites and decides to
become a customer
Customer and service
provider finalise and
conclude the agreement
Figure 5.21: Sample of Service Journey Modelling Language (SJML) [142]
SJML [142] and CJM [89] share a similar abstraction with
ServiceML’s SJM in representing a series of touch-points experienced by
the customer. An example of SJML diagram is provided in figure 5.21.
169
Both SJML and CJM enhanced the touch-point visualization by
providing notations symbolized the interaction mode, e.g. via telephone,
via email, or via website.
CJM is actually a generic label given to types of diagram often used
in service design. Without a single curator role to set the usage standard,
the enhancement and extension of CJM produces various variants. One of
CJM extensions introduces the motivational and emotional aspect of
customers, extended from the pre-service encounter throughout to the
post-service encounter [170][171].
Due to the clear origin of SJML, the modelling language experiences
a more controlled enhancement. A more recent version of SJML adopts
the multi-participant feature of service interactions, as demonstrated in
figure 5.22 [172]. SJML is therefore an important alternative to be
adopted for interaction modelling in the framework.
Send a referral
to a hospital
Register, find
right specialist
Send referral to
the waiting list
Check referral to
process & prepare
standby letter
Referral received
in the system
Referral
forwarded
Assess and
prioritise referral
Referral updated &
information goest to
specialist’s inbox
Receive referral
from GP
Receive the
referral
Receive referral
msg. to process
Referral updated &
information goest to the
waiting listEHR
System
Health
Secretary
Specialist
Document
center
General
Practicioner
Figure 5.22: SJML abstraction for multi-participant interaction [172]
170
An important feature of these new streams of interaction modelling
is in its specification of touch-point type, i.e. manual or software. It
therefore might serve an important role in the framework; to differentiate
between manual services and software services. Only services identified
to be of the software type are required to be processed toward the
software-service design (activity 2.2 in figure 5.6).
A summary of the additional format for the framework artefacts is
presented in the figure 5.23. The proposed alternative metamodels are
offered as a palette of options. The actual usefulness and usability of
these alternatives still required further examination.
2.2 Software Service
Design
2. DESIGN
2.1 Business Service
Design
2.1.2
Interaction
Model
2.1.3
Process
Model
2.1.4
Business Information
Model
2.1.1
Service
Architecture
Model
2.2.1
Atomic
Service
2.2.2
Composite
Service
2.2.4
Service
Detail
Model
2.2.3
Service Information
Model
1.2.1
Business
Modeling
(to-be)
1.1.1
Business
Directives
1. IDENTIFICATION
1.1 Understanding
Service Context
1.2 Defining
Service Concept
1.2.3
Business
Service
(to-be)
1.1.3
Business
Process
(as-is)
1.1.5
Opportunity
Priority
1.1.2
Business
Model
(as-is)
1.1.4
Business
Capabilities
1.2.2
Service
Goal & Value
(to-be)
SoaML
Service
Archit.
SoaML
Interface
SoaML
Service
Interface
SoaML
Message
Type
UML
Behaviour
SoaML
Participant
BPMN
Business
Process
SoaML
Service
Contract.
Service
Blueprint
UML
Class Diagram
BPMN
Business
Process
Component
Business
Model
Business
Model Canvas
Service
Goal
Business
Goals
Business
Service
Catalog
Business
Model
Canvas
Opportunity
List
BMMSoaML
Capabilty
VDML
Capabilty
Library
BM Cube S-BMCSDBM PCNSJMLCJMServiceML
Needs
ServiceML
Serv. Archit.ServiceML
SJM
Alternative Metamodels
Figure 5.23: Metamodels Options for Service Engineering Framework
This chapter describes an exploration toward a modelling concept as
an analysis and design artefact. Despite the recent demand for agility in
the business landscape, a model is still expected to hold an important role
171
in the analysis and design process [173]. The use of metamodels might be
minimized in certain areas, but its usage pattern suggests the existence
of a communication and collaboration space where models will persist, or
even taking a central role, such as envisioned by the Model Driven
Engineering approach [100].
In summary, this chapter provides an elaboration of verification
process for the produced ‘service engineering’ ontologies and framework.
This chapter also explores the metamodel landscape, resulting with
additional metamodel alternatives to be considered into the produced
framework. This new proposition opens new venues for future research
works.
172
Chapter 6
Conclusion
6.1 Summary
The main goal of this research was to compose a consolidated framework for
devising a service system from a business perspective toward a software
perspective labelled as the General Service Engineering Framework (GSEF).
In devising the framework, the research objectives were formalized into four
research questions:
RQ1: What concepts as components should be covered in SvE?
RQ2: What are the activities performed during a SvE?
RQ3: What artefacts should be produced in SvE?
RQ4: In what format should the artefact be presented?
Figure 6.1 summarizes the produced artefacts as response to these
questions within the context of the research structure. The first research
question (RQ1) is examined with ontological approach, discussed in the
third chapter. As a part of the framework, a service engineering
ontological basis is proposed (figure 3.12 and table 3.22). The ontology
specifies components relevant within the context of service engineering
and defines relationship among the concepts.
173
Literature
Review
SOA
Literatures
Classic Service
Engineering
Service
Engineering
Framework(1st iteration)
Case Studies
(First Round)
Service
Ontology
Definition
Software Service
Ontology
Definition
Software Service
Ontology
Service
Engineering
Ontology
Framework vs
Ontology
Mapping
Service
Engineering
Framework(2nd iteration)
Metamodel
Exploration
Service
Engineering
Framework(3rd iteration)
Literature Review
Framework (RQ2, RQ3, RQ4) Ontology (RQ1)
Modeling (RQ4)
Ch 4
Ch 2
Ch 3
Ch 5
IntroductionCh 1
ConclusionCh 6
Case Study
(Second Round)
Service
Engineering
Framework(Generalized)
Activity Artifact
Legend:
Chapter
Number
Ch #
Figure 4.3
Figure 4.19
Figure 4.24
Figure 5.23
Figure 3.12
Table 3.22
Figure 3.14
Table 3.24
Figure #.#
Artifact
Number
Figure 6.1: Map of Research Artefacts
The ontology covers both the business and informatics aspects of
service engineering, i.e., (1) Business Capability, (2) Business Model, (3)
Service Value, (4) Interaction Model, (5) Process Model and, (6) Software-
Service Model. The software-service ontology (figure 3.14) were drawn
from the informatics domain, while the generalized ontology of a service
174
system (figure 3.12) was built from both the business management the
information systems domains.
The rest of the research questions (RQ2, RQ3, and RQ4) are
explored throughout chapter four. Combining the response for these
questions, a GSEF is produced composed from three components derived
from research questions: (1) Stages and activity, (2) Artefacts, and (3)
Format or metamodel. The produced framework was empirically
evaluated with a series of case studies and theoretically validated with
the previously produced ontology. In its final version, the framework
specifies four main activities with sixteen types of artefacts to produce
(figure 4.24).
Additional examination regarding the fourth research question
(RQ4) is discussed in the metamodel exploration of the fifth chapter. A
structured landscape of metamodel offerings from both industrial and
academic circles was composed in the chapter (figure 5.5). The landscape
is a product of exploring potential metamodels for representing an
artefact. The exploration enriches the suggested artefact format from the
original eighteen formats to thirty alternatives of metamodel (figure
5.23).
In summary, the works within this research produced three classes
of contributing artefacts: (1) Service Engineering Framework, (2) Service
Engineering Ontology, and (3) Metamodel Landscape. These artefacts are
listed in table 6.1.
175
Table 6.1: Research Results
Class Artefact Name Location
1 Framework GSEF, first iteration (prototype) Figure 4.3
2 Framework GSEF, second iteration (evaluated) Figure 4.19
3 Framework GSEF, third iteration (validated) Figure 4.24
4 Framework GSEF, fourth iteration (proposed) Figure 5.23
5 Ontology Generals Service Ontology Figure 3.12, table 3.22
6 Ontology Software Service Ontology Figure 3.14, table 3.24
7 Metamodel Landscape MetamodelLandscape Structure Table 5.1, figure 5.4
8 Metamodel Landscape MetamodelLandscape Grouping Figure 5.5
6.3 Limitations and Directions for Future Work
Several limitations are acknowledged from the research scope. First,
the framework is not yet extended into the activity following design stage,
i.e., implementation and evaluation stages. While some case studies were
performed throughout the implementation stage, these activities are not
captured and embedded into the framework, due to the original intended
scope. This decision was made to reduce the complexity of the work by
limiting the framework in a ‘platform-independent’ context.
A grounded conceptual work must be established before answering
the implementation issues, which is inherently technology-specific. This
framework scope limit is the first venue for available future work. A
research challenge in this direction is to define a general abstraction
capturing the variances exist in a ‘platform-specific’ context.
176
The second limitation is in the performance evaluation aspect of the
framework. The research only evaluates the feasibility feature of the
framework, via case studies, while the coverage sufficiency is validated
with ontological comparison. A future work is available in terms of
defining performance criteria to measure the efficiency and effectiveness
of the framework and its components. Performance measurements might
lead to further component modification to improve the overall
performance of the framework, e.g. clarity, simplicity or traceability.
As a general framework, the produced GSEF serves as a template
for further modifications and enhancements. The intentional limitation is
the omission of a specific ‘technique’ in the framework. Future works is
available in the form building a full-prescriptive service engineering
method by specifyingthe ‘how-to’ technique for each activity.This venue
can be undertakenbased on a specific situational context or requirements.
Metamodel exploration is another potential venue to be pursued.
Some metamodels can be considered to be a ‘better’ metamodel than
others. The measuring criteria should be defined, which among others
will be a trade-off between the expressive power, i.e. accuracy, and
simplicity, i.e. comprehensibility [102]. For a stack of metamodels, the
traceability and cross-translatability features will also be the criteria
candidates.
177
Bibliography
[1] S. L. Vargo and R. F. Lusch, “Evolving to a New Dominant Logic for
Marketing,” J. Mark., vol. 68, no. 1, pp. 1–17, 2004.
[2] S. L. Vargo and R. F. Lusch, “Institutions and axioms: an extension
and update of service-dominant logic,” J. Acad. Mark. Sci., vol. 44,
no. 1, pp. 5–23, 2016.
[3] P. Helo, A. Gunasekaran, and A. Rymaszewska, Designing and
Managing Industrial Product-service Systems. Springer, 2016.
[4] C. M. Froehle and A. V. Roth, “New measurement scales for
evaluating perceptions of the technology-mediated customer service
experience,” J. Oper. Manag., vol. 22, no. 1, pp. 1–21, 2004.
[5] J. Cardoso, K. Voigt, and M. Winkler, “Service engineering for the
internet of services,” in International Conference on Enterprise
Information Systems, 2008, vol. 19, pp. 15–27.
[6] H. Luczak, G. Gudergan, and I. I. N. Service, “The Evolution of
Service Engineering—Toward the Implementation of Designing
Integrative Solutions,” Introd. to Serv. Eng., pp. 545–575, 2009.
[7] Y. Baghdadi, “Service-Oriented Software Engineering,” Int. J. Syst.
Serv. Eng., vol. 5, no. 2, pp. 1–19, 2015.
[8] S. Lamparter and Y. Sure, “An interdisciplinary methodology for
building service-oriented systems on the web,” in Services
Computing, 2008. SCC’08. IEEE International Conference on, 2008,
vol. 2, pp. 475–478.
178
[9] A. Pfeiffer, K.-H. Krempels, and M. Jarke, “Service-oriented
Business Model Framework A Service-dominant Logic based
Approach for Business Modeling in the Digital Era,” in 19th
International Conference on Enterprise Information Systems
(ICEIS), At Porto, 2017, no. April.
[10] H. Karhunen, M. Jantti, and A. Eerola, “Service-oriented software
engineering (SOSE) framework,” in Services Systems and Services
Management, 2005. Proceedings of ICSSSM’05. 2005 International
Conference on, 2005, vol. 2, pp. 1199–1204.
[11] D. Fensel, C. Bussler, Y. Ding, and B. Omelayenko, “The Web
Service Modeling Framework WSMF,” Electron. Commer. Res.
Appl., vol. 1, no. 2, pp. 113–137, 2002.
[12] J. S. Gero and U. Kannengiesser, “The situated function–
behaviour–structure framework,” Des. Stud., vol. 25, no. 4, pp. 373–
391, 2004.
[13] L.-C. Wu and L.-H. Wu, “Service Engineering : An
Interdisciplinary Framework,” J. Comput. Inf. Syst., vol. 51, no. 2,
pp. 14–23, 2010.
[14] K. Pohl, “The three dimensions of requirements engineering: A
framework and its applications,” Inf. Syst., vol. 19, no. 3, pp. 243–
258, 1994.
[15] The Open Group, “TOGAF®, an Open Group standard | The Open
Group,” 2018. [Online]. Available:
http://www.opengroup.org/subjectareas/enterprise/togaf. [Accessed:
07-Jun-2017].
179
[16] D. A. C. Quartel, M. W. A. Steen, S. Pokraev, and M. J. Van
Sinderen, “COSMO: A conceptual framework for service modelling
and refinement,” Inf. Syst. Front., vol. 9, no. 2–3, pp. 225–244, 2007.
[17] R. der Merwe and J. Bekker, “A framework and methodology for
evaluating e-commerce web sites,” Internet Res., vol. 13, no. 5, pp.
330–341, 2003.
[18] J. Fitzsimmons, Service Management: Operations, Strategy, and
Information Technology, Fifth Edit. Mc Graw Hill, 2006.
[19] R. H. Von Alan et al., “Design science in information systems
research,” MIS Q., vol. 28, no. 1, pp. 75–105, 2004.
[20] A. R. Hevner, “A Three Cycle View of Design Science Research,”
Scand. J. Inf. Syst., vol. 19, no. 2, pp. 87–92, 2007.
[21] R. K. Yin and S. Editors, Applications of case study research. Sage,
2011.
[22] S. E. Sampson, “The unified service theory,” in Handbook of service
science, Springer, 2010, pp. 107–131.
[23] R. G. Qiu, Service science: The foundations of service engineering
and management. John Wiley & Sons, 2014.
[24] T. Erl, Service-Oriented Architecture: Concepts, Technology, and
Design. Pearson Education, 2005.
[25] G. Pezzotta, R. Pinto, F. Pirola, and M.-Z. Ouertani, “Balancing
Product-service Provider’s Performance and Customer’s Value: The
SErvice Engineering Methodology (SEEM),” Procedia CIRP, vol. 16,
180
pp. 50–55, 2014.
[26] H. J. Bullinger, K. P. Fähnrich, and T. Meiren, “Service
engineering—methodical development of new service products,” Int.
J. Prod. Econ., vol. 85, no. 3, pp. 275–287, 2003.
[27] D. Beverungen et al., “Recombinant Service System Engineering,”
Bus. Inf. Syst. Eng., no. Preprints, pp. 136–150, 2018.
[28] S. P. Johnson, L. J. Menor, A. V Roth, and R. B. Chase, “A critical
evaluation of the new service development process,” New Serv. Dev.
Creat. Memorab. Exp., pp. 1–32, 2000.
[29] J. Spohrer and P. P. Maglio, “The Emergence of Service Science:
Toward Systematic Service Innovations to Accelerate Co-Creation of
Value,” Prod. Oper. Manag., vol. 17, no. 3, pp. 238–246, 2008.
[30] J. Spohrer, “Services sciences, management, and engineering
(SSME) and its relation to academic disciplines,” in Services
Science, Springer, 2008, pp. 11–40.
[31] F. Lin and P.-S. Hsieh, “A SAT view on new service development,”
Serv. Sci., vol. 3, no. 2, pp. 141–157, 2011.
[32] A. J. Lopes and R. Pineda, “Service systems engineering
applications,” Procedia Comput. Sci., vol. 16, pp. 678–687, Jan.
2013.
[33] Axelos, “ITIL® - IT Service Management.” [Online]. Available:
https://www.axelos.com/best-practice-solutions/itil. [Accessed: 10-
Apr-2018].
181
[34] OASIS, “Reference Model for Service Oriented Architecture v1.0.”
[Online]. Available: https://docs.oasis-open.org/soa-rm/v1.0/soa-
rm.html. [Accessed: 10-Apr-2018].
[35] O. Zimmermann, P. Krogdahl, and C. Gee, “Elements of service-
oriented analysis and design,” IBM Dev., pp. 1–18, 2004.
[36] Y. Baghdadi, “A comparison framework for service-oriented
software engineering approaches: Issues and solutions,” Int. J. Web
Inf. Syst., vol. 9, no. 4, pp. 279–316, 2013.
[37] I. Sommerville, Software engineering. New York: Addison-Wesley,
2010.
[38] M. Anjum and D. Budgen, “A mapping study of the definitions for
service oriented architecture,” in 16th International Conference on
Evaluation & Assessment in Software Engineering (EASE 2012),
2012, pp. 57–61.
[39] M. F. Gholami, J. Habibi, F. Shams, and S. Khoshnevis, “Criteria-
Based evaluation framework for service-oriented methodologies,” in
Computer Modelling and Simulation (UKSim), 2010 12th
International Conference on, 2010, pp. 122–130.
[40] M. P. Papazoglou and V. Den Heuvel, “Service-oriented design and
development methodology,” Int. J. Web Eng. Technol., vol. 2, no. 4,
p. 412, 2006.
[41] C. Emig, J. Weisser, and S. Abeck, “Development of soa-based
software systems-an evolutionary programming approach,” in
Telecommunications, 2006. AICT-ICIW’06. International
182
Conference on Internet and Web Applications and
Services/Advanced International Conference on, 2006, p. 182.
[42] K. Mittal, “Service-Oriented Unified Process,” IBM developerWorks,
2006. [Online]. Available:
https://www.ibm.com/developerworks/library/ws-soa-
method3/index.html. [Accessed: 11-Apr-2018].
[43] S. Jones, “A Methodology for Service Architectures,” 2005.
[44] A. Erradi, S. Anand, and N. Kulkarni, “SOAF: An architectural
framework for service definition and realization,” in Services
Computing, 2006. SCC’06. IEEE International Conference on, 2006,
pp. 151–158.
[45] P. Allen, “CBDI-SAE Reference Framework,” CBDI Journal, 2007.
[Online]. Available: http://everware-cbdi.com/products/framework-
products/cbdi-sae-framework. [Accessed: 11-Apr-2018].
[46] S. H. Chang and S. D. Kim, “A service-oriented analysis and design
approach to developing adaptable services,” Proc. - 2007 IEEE Int.
Conf. Serv. Comput. SCC 2007, no. 10557, pp. 204–211, 2007.
[47] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, and
K. Holley, “SOMA : A method for developing service-oriented
solutions,” IBM Syst. J., vol. 47, no. 3, pp. 377–396, 2008.
[48] G. Engels et al., “A Method for Engineering a True Service-Oriented
Architecture.,” in ICEIS (3-2), 2008, pp. 272–281.
[49] E. Ramollari, D. Dranidis, and A. J. H. Simons, “A survey of service
oriented development methodologies,” 2nd Eur. Young Res. Work.
183
Serv. Oriented Comput., vol. 75, pp. 1–6, 2007.
[50] M. Emadi, M. D. Jazi, R. A. Moghadam, and F. Bahredar, “An
improved methodology for service oriented architecture,” in 2012
IEEE International Conference on Computer Science and
Automation Engineering (CSAE), 2012, vol. 2, pp. 350–354.
[51] Q. Gu and P. Lago, “Guiding the selection of service-oriented
software engineering methodologies,” Serv. Oriented Comput. Appl.,
vol. 5, no. 4, pp. 203–223, 2011.
[52] M. Ernest and J. M. Nisavic, “Adding value to the IT organization
with the Component Business Model,” IBM Syst. J., vol. 46, no. 3,
pp. 387–403, 2007.
[53] T. Kohlborn, A. Korthaus, T. Chan, M. Rosemann., and M.
Rosemann, “Identification and analysis of business and software
services-a consolidated approach,” IEEE Trans. Serv. Comput., vol.
2, no. 1, pp. 50–64, 2009.
[54] M. Mohammadi and M. Mukhtar, “A Review of SOA Modeling
Approaches for Enterprise Information Systems,” Procedia
Technol., vol. 11, no. 0, pp. 794–800, 2013.
[55] N. M. Nik Daud and W. M. N. Wan Kadir, “Generic analysis
metamodel based on service oriented software design,” J. Theor.
Appl. Inf. Technol., vol. 73, no. 3, pp. 346–353, 2015.
[56] OMG, “Unified Modeling Language (UML),” Object Management
Group (OMG) Specification, 2017. [Online]. Available:
http://www.omg.org/spec/UML/. [Accessed: 08-Jun-2017].
184
[57] G. Benguria, X. Larrucea, B. Elvesæter, T. Neple, A. Beardsmore,
and M. Friess, “A platform independent model for service oriented
architectures,” in Enterprise interoperability, Springer, 2007, pp.
23–32.
[58] J. J. Abreu and J. L. Fiadeiro, “A coordination model for service-
oriented interactions,” in International Conference on Coordination
Languages and Models, 2008, vol. 5052 LNCS, pp. 1–16.
[59] M. Bell, Service-oriented modeling (SOA): Service analysis, design,
and architecture. John Wiley & Sons, 2008.
[60] OMG, “Service oriented architecture Modeling Language (SoaML)
Specification,” Object Management Group (OMG) Specification,
2012. [Online]. Available: http://www.omg.org/spec/SoaML/.
[Accessed: 07-Jun-2017].
[61] H. Gomaa, Software modeling and design: UML, use cases,
patterns, and software architectures. Cambridge University Press,
2011.
[62] M. Anjum and D. Budgen, “An investigation of modelling and
design for software service applications,” PLoS One, vol. 12, no. 5, p.
e0176936, 2017.
[63] I. Todoran, Z. Hussain, and N. Gromov, “SOA integration modeling:
An evaluation of how SoaML completes UML modeling,” in
Enterprise Distributed Object Computing Conference Workshops
(EDOCW), 2011 15th IEEE International, 2011, pp. 57–66.
[64] I. Tounsi, M. H. Kacem, and A. H. Kacem, “An approach for
185
modeling and formalizing SOA design patterns,” in Enabling
Technologies: Infrastructure for Collaborative Enterprises
(WETICE), 2013 IEEE 22nd International Workshop on, 2013, pp.
330–335.
[65] V. Hrgovcic, W. Utz, and D. Karagiannis, “Service Modeling: A
Model Based Approach for Business and IT Alignment,” 2011 IEEE
35th Annu. Comput. Softw. Appl. Conf. Work., pp. 422–427, 2011.
[66] M. an Airchinnigh, H.-J. Kugler, C. Science, and T. Limited,
“Service engineering versus software engineering,” in International
Conference on Intelligence in Services and Networks, 1994, pp. 39–
49.
[67] H.-M. Chen, R. Kazman, and O. Perry, “From Software Architecture
Analysis to Service Engineering: An Empirical Study of
Methodology Development for Enterprise SOA Implementation,”
IEEE Trans. Serv. Comput., vol. 3, no. 2, pp. 145–160, 2010.
[68] W. D. Yu and C. H. Ong, “A SOA Based Software Engineering
Design Approach in Service Engineering,” 2009 IEEE Int. Conf. E-
bus. Eng., 2009.
[69] J. F. Santanna-Filho, R. J. Rabelo, A. A. Pereira-Klen, P. Bernus,
and D. Romero, “Leveraging collaborative innovation in SOA-based
software providers networks,” in Engineering, Technology and
Innovation/International Technology Management Conference
(ICE/ITMC), 2015 IEEE International Conference on, 2015, no.
July, pp. 1–9.
[70] G. Guizzardi, “On ontology, ontologies, conceptualizations, modeling
186
languages, and (meta) models,” Front. Artif. Intell. Appl., vol. 155,
p. 18, 2007.
[71] U. Aßmann, S. Zschaler, and G. Wagner, “Ontologies, meta-models,
and the model-driven paradigm,” in Ontologies for software
engineering and software technology, Springer, 2006, pp. 249–273.
[72] M. Saeki and H. Kaiya, “On relationships among models, meta
models and ontologies,” in Proceedings of the 6th OOPSLA
Workshop on Domain-Specific Modeling (DSM 2006), 2006.
[73] S. H. Chang, “A systematic analysis and design approach to develop
adaptable services in service oriented computing,” in Services, 2007
IEEE Congress on, 2007, no. 2, pp. 375–378.
[74] J. Dodd, P. Allen, J. Butler, S. Olding, R. Veryard, and L. Wilkes,
“CBDI-SAE Meta Model for SOA Version 3,” 2009.
[75] Z. Ma, L. Kang, and H. Chen, “An Approach to Modeling Service-
Oriented Solutions based on CBDI-SAE Metamodel for SOA 2.0,” in
Service Oriented System Engineering (SOSE), 2010 Fifth IEEE
International Symposium on, 2010, pp. 82–85.
[76] H. Kreger and J. Estefan, “Navigating the soa open standards
landscape around architecture,” Jt. Pap. Open Group, OASIS,
OMG, 2009.
[77] J. Amsden, “Modeling with soaml, the service-oriented architecture
modeling language,” IBM, Tech. Artic. Ser. January-February, pp.
1–22, 2010.
[78] B. Elvesæter, A.-J. Berre, and A. Sadovykh, “Specifying Services
187
using the Service Oriented Architecture Modeling Language
(SoaML)-A Baseline for Specification of Cloud-based Services.,” in
CLOSER, 2011, pp. 276–285.
[79] C. Casanave, “Service oriented architecture using the omg soaml
standard,” 2009.
[80] International Organization for Standardization (ISO), “ISO/IEC
18384:2016 - Reference Architecture for Service Oriented
Architecture (SOA RA).” [Online]. Available:
https://www.iso.org/standard/63104.html. [Accessed: 20-Apr-2018].
[81] R. J. Machado, J. M. Fernandes, P. Monteiro, and H. Rodrigues,
“Transformation of UML models for service-oriented software
architectures,” in Engineering of Computer-Based Systems, 2005.
ECBS’05. 12th IEEE International Conference and Workshops on
the, 2005, pp. 173–182.
[82] V. Bicer, S. Lamparter, Y. Sure, and A. H. Dogru, “Towards an
interdisciplinary methodology for service-oriented system
engineering,” in Computer and Information Sciences, 2009. ISCIS
2009. 24th International Symposium on, 2009, pp. 486–491.
[83] A. Osterwalder, “The Business Model Ontology-a proposition in a
design science approach,” PhD dissertation, University of
Lausanne, Switzerland, 2004.
[84] C. Ehrenhöfer and E. Kreuzer, “The role of business model design in
the service engineering process: a comparative case study in the
field of cloud computing to join service engineering with business
model design,” in SRII Global Conference (SRII), 2012 Annual,
188
2012, pp. 283–292.
[85] A. Osterwalder, Y. Pigneur, A. Smith, and T. Movement, “Business
model canvas,” Self Publ. Last, 2010.
[86] T. Hara, T. Arai, and Y. Shimomura, “A Concept of Service
Engineering: A Modeling Method and A Tool for Service Design,”
2006 Int. Conf. Serv. Syst. Serv. Manag., pp. 13–18, 2006.
[87] M. Mukhtar, M. N. Ismail, and Y. Yahya, “A hierarchical
classification of co-creation models and techniques to aid in product
or service design,” Comput. Ind., vol. 63, no. 4, pp. 289–297, 2012.
[88] M. J. Bitner, A. L. Ostrom, and F. N. Morgan, “Service blueprinting:
a practical technique for service innovation,” Calif. Manage. Rev.,
vol. 50, no. 3, pp. 66–94, 2008.
[89] M. Stickdorn, J. Schneider, K. Andrews, and A. Lawrence, This is
service design thinking: Basics, tools, cases. Wiley Hoboken, NJ,
2011.
[90] W. Miao and S. Liu, “A formal engineering framework for service-
based software modeling,” IEEE Trans. Serv. Comput., vol. 6, no. 4,
pp. 536–550, 2013.
[91] D. Bianchini, C. Cappiello, V. De Antonellis, and B. Pernici,
“Service identification in interorganizational process design,” IEEE
Trans. Serv. Comput., vol. 7, no. 2, pp. 265–278, 2014.
[92] B. Elvesæter, C. Carrez, P. Mohagheghi, A.-J. Berre, S. G. Johnsen,
and A. Solberg, “Model-driven service engineering with SoaML,” in
Service Engineering, Springer, 2011, pp. 25–54.
189
[93] OMG, “Business Process Model And Notation (BPMN)
Specification,” Object Management Group (OMG) Specification,
2014. [Online]. Available: https://www.omg.org/spec/BPMN.
[Accessed: 10-Apr-2018].
[94] G. Pohle, P. Korsten, and S. Ramamurthy, “Component business
models: Making specialization real,” IBM Inst. Bus. Value. August,
vol. 19, 2005.
[95] M. Lankhorst, “Enterprise Architecture at Work: Modelling,
Communication and Analysis (The Enterprise Engineering Series),”
2009.
[96] U. J. Gelinas, S. G. Sutton, and J. Fedorowicz, Business processes
and information technology. Thomson/South-Western Mason Ohio,
2004.
[97] T. DeMarco, Structure Analysis and System Specification. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2001.
[98] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorenzen,
“Object-Oriented Modeling and Design,” p. 449, 1991.
[99] M. P. Papazoglou and D. Georgakopoulos, “Service-oriented
computing,” Commun. ACM, vol. 46, no. 10, pp. 24–28, 2003.
[100] D. Gasevic, D. Djuric, and V. Devedzic, Model Driven Engineering
and Ontology Development, vol. XXI. 2009.
[101] OMG, “OMG Formal Specifications,” Object Management Group
(OMG) Specification, 2017. [Online]. Available:
http://www.omg.org/spec/. [Accessed: 07-Jun-2017].
190
[102] B. Selic, “The pragmatics of model-driven development,” IEEE
Softw., vol. 20, no. 5, pp. 19–25, 2003.
[103] E. Seidewitz, “What models mean,” IEEE Softw., vol. 20, no. 5, pp.
26–32, 2003.
[104] S. J. Mellor, T. Clark, and T. Futagami, “Model-driven development:
guest editors’ introduction.,” IEEE Softw., vol. 20, no. 5, pp. 14–18,
2003.
[105] H. Dubberly, S. Evenson, D. Design, S. E. Fjord, and R. R. Sapient,
“On modeling The analysis-systhesis bridge model,” interactions,
vol. 15, no. 2, pp. 57–61, 2008.
[106] D. Moody, “The ‘physics’ of notations: toward a scientific basis for
constructing visual notations in software engineering,” IEEE Trans.
Softw. Eng., vol. 35, no. 6, pp. 756–779, 2009.
[107] M. Brambilla, J. Cabot, and M. Wimmer, “Model-driven software
engineering in practice,” Synth. Lect. Softw. Eng., vol. 1, no. 1, pp.
1–182, 2012.
[108] C. Carnaghan, “Business process modeling approaches in the
context of process level audit risk assessment: An analysis and
comparison,” Int. J. Account. Inf. Syst., vol. 7, no. 2, pp. 170–204,
2006.
[109] D. Bork, H.-G. G. Fill, K. Engineering, H.-G. G. Fill, and K.
Engineering, “Formal aspects of enterprise modeling methods: a
comparison framework,” in System Sciences (HICSS), 2014 47th
Hawaii International Conference on, 2014, no. Dd, pp. 3400–3409.
191
[110] D. C. C. Peixoto, V. a Batista, A. P. Atayde, and E. P. Borges, “A
Comparison of BPMN and UML 2 . 0 Activity Diagrams,” Work, vol.
3, no. February 2016, pp. 1–14, 2007.
[111] O. Noran, “UML vs. IDEF: An Ontology-Oriented Comparative
Study in View of Business Modelling.,” in ICEIS 2004 - Proceedings
of the Sixth International Conference on Enterprise Information
Systems, 2004, no. April 2004, pp. 674–682.
[112] J. G. Henriques, P. C. Oliveira, M. M. da Silva, and M. Mira,
“Modelling languages restrictions: A comparative study of
archimate and somf,” in Virtual and Networked Organizations,
Emergent Technologies and Tools, vol. 248 CCIS, no. January 2011,
Springer, 2012, pp. 273–282.
[113] Y. Kazemzadeh, S. K. Milton, and L. W. Johnson, “An explication of
three service business process modeling approaches,” Aust. J. Bus.
Econ. Stud., vol. 1, no. 2, pp. 40–53, 2015.
[114] R. S. Pressman, Software engineering: a practitioner’s approach.
Palgrave Macmillan, 2005.
[115] INCOSE and C. Haskins, Systems engineering handbook: A guide
for system life cycle processes and activities. International Council
of Systems Engineering, 2011.
[116] J. A. Zachman, “A framework for information systems architecture,”
IBM Syst. J., vol. 26, no. 3, pp. 276–292, 1987.
[117] Open Group, “The Open Group Architecture Forum (TOGAF),”
2017. [Online]. Available:
192
http://www.opengroup.org/subjectareas/enterprise/togaf. [Accessed:
08-Jun-2017].
[118] B. G. Glaser and A. L. Strauss, The discovery of grounded theory:
Strategies for qualitative research. Transaction publishers, 2009.
[119] M. B. Miles and A. M. Huberman, Qualitative data analysis: An
expanded sourcebook. sage, 1994.
[120] R. Winter, A. Gericke, T. Bucher, P. By, G. Almeida, and V. S. Date,
“Method Versus Model--Two Sides of the Same Coin?,” in Advances
in Enterprise Engineering III, Springer, 2009, pp. 1–15.
[121] J. Wheeldon and J. Faubert, “Framing experience: Concept maps,
mind maps, and data collection in qualitative research,” Int. J.
Qual. Methods, vol. 8, no. 3, pp. 68–83, 2009.
[122] S. Overbeek, U. Frank, and C. Köhling, “A language for multi-
perspective goal modelling: Challenges, requirements and
solutions,” Comput. Stand. Interfaces, vol. 38, no. September, pp. 1–
16, 2015.
[123] U. Frank, “Multi-perspective enterprise modelling: Background and
terminological foundation,” 2011.
[124] A. Van Lamsweerde, L. Willemet, A. Van Lamsweerde, and L.
Willemet, “Inferring declarative requirements specifications from
operational scenarios,” IEEE Trans. Softw. Eng., vol. 24, no. 12, pp.
1089–1114, 1998.
[125] D. Amyot, “Introduction to the user requirements notation:
Learning by example,” Comput. Networks, vol. 42, no. 3, pp. 285–
193
301, 2003.
[126] E. S. K. Yu, “Towards modelling and reasoning support for early-
phase requirements engineering,” in Requirements Engineering,
1997., Proceedings of the Third IEEE International Symposium on,
1997, pp. 226–235.
[127] G. Berio, V. Anaya, and Á. Ortiz, “Supporting enterprise integration
through a unified enterprise modeling language,” CEUR Workshop
Proc., vol. 125, no. May 2014, pp. 165–176, 2004.
[128] OMG, “Ontology Definition Metamodel (ODM) Specification,” Object
Management Group (OMG) Specification, 2014. [Online]. Available:
http://www.omg.org/spec/ODM/. [Accessed: 07-Jun-2017].
[129] A.-W. Scheer, Business process engineering: reference models for
industrial enterprises. Springer Science & Business Media, 2012.
[130] N. Malik, “Enterprise business motivation model,” Full Model Doc.
version, vol. 3, 2009.
[131] K. Hinkelmann and M. Suter, “Extending business motivation
modelling to foster regional flexibility in IT architecture
management,” in eChallenges e-2013 Conference Proceedings, 2013.
[132] OMG, “Business Motivation Model (BMM),” Object Management
Group (OMG) Specification, 2015. [Online]. Available:
http://www.omg.org/spec/BMM/. [Accessed: 07-Jun-2017].
[133] T. Chang, A. J. Berre, C. Carrez, and B. Elvesæter, “Business-
soaml: Service identification and specification from a business
perspective,” in Enterprise Interoperability V, Springer, 2012, pp.
194
379–389.
[134] P. Lindgren and O. H. Rasmussen, “The business model cube,” J.
Multi Bus. Model Innov. Technol., vol. 1, no. 2, pp. 135–182, 2013.
[135] A. Zolnowski, C. Weiß, and T. Bohmann, “Representing Service
Business Models with the Service Business Model Canvas--The
Case of a Mobile Payment Service in the Retail Industry,” in system
sciences (HICSS), 2014 47th Hawaii International Conference on,
2014, pp. 718–727.
[136] E. Lüftenegger, Service-dominant business design, vol. 402, no.
January. Eindhoven University of Technology, 2014.
[137] W. Ulrich, S. Consultant, C. Consortium, and M. Rosen, “The
business capability map: the‘ rosetta stone’ of business/it
alignment,” Cut. Consortium, Enterp. Archit., vol. 24, no. 4, 2011.
[138] OMG, “Value Delivery Modeling Language (VDML),” Object
Management Group (OMG) Specification, 2015. [Online]. Available:
http://www.omg.org/spec/VDML/. [Accessed: 08-Jun-2017].
[139] J. Gordijn and H. Akkermans, A Conceptual Modeling Approach for
e-Business Development, vol. 27. Citeseer, 2001.
[140] V. Allee, “Reconfiguring the value network,” J. Bus. Strategy, vol.
21, no. 4, pp. 36–39, 2000.
[141] A. J. Berre, H. de Man, Y. Lew, B. Elvesæter, and B. M. Ursin-
Holm, “Open business model, process and service innovation with
VDML and ServiceML,” in Enterprise Interoperability: Research
and Applications in Service-oriented Ecosystem (Proceedings of the
195
5th International IFIP Working Conference IWIE 2013), 2013, vol.
X, no. X, p. 127.
[142] R. Halvorsrud, E. Lee, I. M. Haugstveit, and A. Følstad,
“Components of a visual language for service design,” in ServDes.
2014 Service Future; Proceedings of the fourth Service Design and
Service Innovation Conference; Lancaster University; United
Kingdom; 9-11 April 2014, 2014, no. 99, pp. 291–300.
[143] S. E. Sampson, “Visualizing service operations,” J. Serv. Res., vol.
15, no. 2, pp. 182–198, 2012.
[144] C. V. Scheller and P. Hruby, “Business process and value delivery
modeling using possession, ownership, and availability (POA) in
enterprises and business networks,” J. Inf. Syst., vol. 30, no. 2, pp.
5–47, 2014.
[145] M. Rother and J. Shook, Learning to see: value stream mapping to
add value and eliminate muda. Lean Enterprise Institute, 2003.
[146] OMG, “Semantics of Business Vocabulary and Rules (SBVR),”
Object Management Group (OMG) Specification, 2017. [Online].
Available: http://www.omg.org/spec/SBVR/. [Accessed: 08-Jun-2017].
[147] B. Von Halle and L. Goldberg, The decision model: a business logic
framework linking business and technology. CRC Press, 2009.
[148] OMG, “Decision Model and Notation (DMN),” Object Management
Group (OMG) Specification, 2016. [Online]. Available:
http://www.omg.org/spec/DMN/. [Accessed: 08-Jun-2017].
[149] OMG, “Case Management Model and Notation (CMMN),” Object
196
Management Group (OMG) Specification, 2016. [Online]. Available:
http://www.omg.org/spec/CMMN/. [Accessed: 07-Jun-2017].
[150] OMG, “Busines Process Definition Metamodel (BPDM),” Object
Management Group (OMG) Specification, 2004. [Online]. Available:
http://www.omg.org/spec/BPDM/. [Accessed: 08-Jun-2017].
[151] OMG, “Business Process Model and Notation (BPMN),” Object
Management Group (OMG) Specification, 2011. [Online]. Available:
http://www.omg.org/spec/BPMN/. [Accessed: 08-Jun-2017].
[152] J. Mendling, “Event-driven process chains (epc),” Metrics Process
Model., pp. 17–57, 2009.
[153] W. E. McCarthy, “The REA accounting model: A generalized
framework for accounting systems in a shared data environment,”
Account. Rev., pp. 554–578, 1982.
[154] W. M. P. van der Aalst and A. H. M. Ter Hofstede, “YAWL: yet
another workflow language,” Inf. Syst., vol. 30, no. 4, pp. 245–275,
2005.
[155] OMG, “Interaction Flow Modeling Language (IFML),” Object
Management Group (OMG) Specification, 2016. [Online]. Available:
http://www.omg.org/spec/IFML/. [Accessed: 08-Jun-2017].
[156] W. P. Stevens, G. J. Myers, and L. L. Constantine, “Structured
design,” IBM Syst. J., vol. 13, no. 2, pp. 115–139, 1974.
[157] P. P.-S. Chen, “The entity-relationship model—toward a unified
view of data,” ACM Trans. Database Syst., vol. 1, no. 1, pp. 9–36,
1976.
197
[158] OMG, “Systems Modeling Language (SysML),” Object Management
Group (OMG) Specification, 2017. [Online]. Available:
http://www.omg.org/spec/SysML/. [Accessed: 08-Jun-2017].
[159] C. Menzel and R. J. Mayer, “The IDEF family of languages,” in
Handbook on architectures of information systems, no. January
2006, Springer, 1998, pp. 209–241.
[160] H. H. Goldstine and J. Von Neumann, Planning and coding of
problems for an electronic computing instrument, vol. 2. Institute
for Advanced Study Princeton, N. J, 1948.
[161] D. Harel, “Statecharts: A visual formalism for complex systems,”
Sci. Comput. Program., vol. 8, no. 3, pp. 231–274, 1987.
[162] J. L. Peterson, “Petri net theory and the modeling of systems,” 1981.
[163] A. Albani and J. L. G. Dietz, Advances in Enterprise Engineering
III: 5th International Workshop, Ciao! 2009, and 5th International
Workshop, Eomas 2009, Held at Caise 2009, Amsterdam, the
Netherlands, June 8-9, 2009, Proceedings, vol. 34. Springer Science
& Business Media, 2009.
[164] U. Frank, “Multi-perspective enterprise modeling: foundational
concepts, prospects and future research challenges,” Softw. Syst.
Model., vol. 13, no. 3, pp. 941–962, 2014.
[165] V. Anaya et al., “The Unified Enterprise Modelling Language-
Overview and further work,” Comput. Ind., vol. 61, no. 2, pp. 99–
111, 2010.
[166] W. M. P. Van Der Aalst and W. M. P. Van Der Aalst, “Business
198
process management: a comprehensive survey,” ISRN Softw. Eng.,
vol. 2013, 2013.
[167] M. Petre, P. Roques, M. Petre, and P. Roques, “UML in practice,” in
Proceedings of the 2013 International Conference on Software
Engineering, 2013, pp. 722–731.
[168] C.-H. Kim, R. H. Weston, A. Hodgson, and K.-H. Lee, “The
complementary use of IDEF and UML modelling approaches,”
Comput. Ind., vol. 50, no. 1, pp. 35–56, 2003.
[169] R. Tõnisson and R. Matulevičius, “A Coarse-Grained Comparison of
Modelling Languages for Business Motivation and Intentional
Distribution,” in International Conference on Business Informatics
Research, 2016, pp. 80–95.
[170] M. S. Rosenbaum, M. L. Otalora, and G. C. Ramirez, “How to create
a realistic customer journey map,” Bus. Horiz., vol. 60, no. 1, pp.
143–150, 2017.
[171] B. D. Temkin, “Mapping The Customer Journey,” Forrester Res.,
2010.
[172] E. Lee, A. Karahasanovic, and R. Halvorsrud, “A visual language
for the modelling of service delivery processes to support business
processes management,” Int. J. Adv. Softw., vol. 8, no. 3 & 4, pp.
288–308, 2015.
[173] Z. Babar, A. Lapouchnian, and E. Yu, “Modeling DevOps
deployment choices using process architecture design dimensions,”
in IFIP Working Conference on The Practice of Enterprise
199
Modeling, 2015, vol. 2, pp. 322–337.