A Methodological Approach to Support Cloud

A Methodological Approach to Support Cloud Computing Migration

by

Mahdi Fahmideh Gholami

A thesis in fulfilment of the requirements for the degree of Doctor of Philosophy

School of Information Systems, Technology and Management Australian Business School

Supervisors: Dr. Farhad Daneshgar Professor Fethi Rabhi

July 2017

Acknowledgements Often acknowledgments are readable at the end of a movie making tribute to those a person is indebted. Similarly, I would like to recapture my PhD journey by introducing the names of characters that came in the stages of this long journey. Any story needs a background. As Kant Heidegger mentioned, nothing can exist in itself unless a backdrop that allows it to come into existence. My story is not exceptional and the stage on which my thesis is found is in love and kindness of people who helped me. Hence, and foremost, I am in debt to my beloved parents, Mokhtar and Narges, for their trust, understanding, endurance, and giving value to education, and providing emotional support over four years. They showed me that it can be done. My PhD journey, started before it began while I was working with Dr. Raman Ramsin at Sharif University, Dr. Fereidon Shams at Shahid Beheshti University, and Professor Mohsen Sharifi at Iran University of Science and Technology at Tehran, Iran. The atmosphere they made for me during working with them encouraged me to pursue a doctoral degree. The outcome of this collaboration provided to me a potential for granting a University International Postgraduate Award (UIPA) and a faculty top-up scholarship by Australian School of Business that allowed me to start my PhD program at University of New South Wales (UNSW) in Sydney, Australia. Undoubtedly, the most important character in my PhD program was my supervisor Dr. Farhad Daneshgar who was willing to take me on as his student and to undertake such a challengeable journey. He trained me to become a researcher by showing a deep knowledge in conducting rigorous research. Especially, I would like to thank Professor Fethi Rabhi, my joint-supervisor, for his invaluable help, guidance, and encouragement throughout my PhD program. In addition, I am also in debt to Professor Graham Low and Dr. Ghassan Beydoun who help me on conducting some technical aspect of this research. They guided me to explain my idea to those who are not familiar with my research in a consistent and clear manner. Thanks to their meticulous comments. I would also like to express my gratitude to Professor Kieran Conboy who has provided valuable feedback at the early stage of my research. I had a great chance to work with him and have his great advice. I am also thankful to A/Professor Aybüke Aurum and Professor Dubravka Cecez-Kecmanovic for

V

their valuable comments for conducting literature reviews. I would like thank to my PhD panel members Dr. John D’Ambra, Professor Pradeep Ray, Dr. Lesley Land, Dr. Daniel Schlagwein, and Dr. Felix Ter Chian Tan for their time they spent to review my research proposal and providing constructive comments to improve my research. I thank Professor Shan Pan for taking the time to talk to me about my research and share with me his profound knowledge in doing high quality research. Finally, I would like to thank my friends who directly or indirectly commented on my work, notably Behrang Assemi, Shahla Ghobadi, Katja Ignatieva, Arash Dadras, Pooyan Jamshidi, Anastasia Utesheva, Ramtin Kazemi, and Sepideh Mehrjoya. Their comments help me to improve my research. As I will surely forget to list all friends, please accept my sincere “Thank You!”

VI

List of Publications Below is a list of journal articles and conference papers which have either been published or are under review. Journal Articles Mahdi Fahmideh, Farhad Daneshgar, Graham Low, Ghassan Beydoun, “Cloud Migration Process— A Survey, Evaluation Framework, and Open Challenges”, Journal of Systems and Software, Vol 120, October 2016, pp. 31-69. Mahdi Fahmideh, Farhad Daneshgar, Ghassan Beydoun, Fethi Rabhi “Challenges in migrating legacy software systems to the cloud — an empirical study”, Gholami, Mahdi Fahmideh, et al. "Challenges in migrating legacy software systems to the cloud—an empirical study." Information Systems 67 (2017): 100-113. Conference Papers Mahdi Fahmideh, Graham Low, Ghassan Beydoun, “Conceptualising Cloud Migration Process”, Proceedings of Twenty-Fourth European Conference on Information Systems (ECIS), 2016, Istanbul, Turkey. Mahdi Fahmideh, Farhad Daneshgar, Fethi Rabhi “Cloud Migration Methodologies Preliminary Findings”, Second International Workshop on Cloud Adoption and Migration September 2016, Vienna, Austria, 2016, In Press. Mahdi Fahmideh, Farhad Daneshgar, Fethi Rabhi, “Cloud Computing Migration: An Effective Tailoring Approach”, Twenty-Seventh Australian Conference on Information Systems-ACIS 2016 (ACIS).

VII

Abbreviations and Symbols Abbreviation

Description

API

Application Programming Interface

BPEL

Business Process Execution Language

CRM

Customer Relationship Management

IaaS

Infrastructure a as Service

IP

Internet Protocol

IS

Information Systems

ISD

Information System Development

MDSE

Model-Driven Software Engineering

MOF

Meta Object Facility

OPEN

Object-oriented Process, Environment, and Notation

PaaS

Platform as a Service

PDA

Personal Digital Assistant (electronic handheld information device)

SaaS

Software as a Service

SLA

Service Level Agreement

SLR

Systematic Literature Review

SOA

Service Oriented Architecture

SPEM

Software Process Engineering Metamodel

UML

Unified Modelling Language

WSDL

Web Service Description Language

VIII

Abstract Context. The growing prevalence and potential impact of cloud computing technology have sparked significant attention amongst IT industry and academia. It offers potential clients a wide range of services which are universally accessible, acquirable, releasable, and payable on the fly based on the amount of usage. Many IT-based organisations are moving their legacy software applications to cloud environments. An effective method for conducting such transition is crucial to a successful migration. The literature review reveals that the methodological aspect of the cloud migration has not been well addressed, despite calls expressed by several researchers to resolve this issue. The existing knowledge about cloud migration process is fragmented over the literature, narrow in tactical focus with heterogeneous viewpoints, and lacking support for creating customised methods, that fit given cloud migration scenarios. Objective. By adopting the design science paradigm, this research proposes a framework, which provides a generic process model of cloud migration with associated guidelines. The model can be reused and tailored for creating, configuring, and maintaining situational methods for various cloud migration scenarios. Method. The proposed framework is based a model-driven software development approach and offers two functionalities: (i) an overarching and platform-independent process model which captures domain constructs relevant to the cloud migration which a typical cloud migration may entail; and (ii) a tailoring procedure which aids creating, fine-tuning, standardising, and sharing situational methods for given cloud migration scenarios through reusing the process model. The framework is iteratively evaluated and refined by feedback received from domain experts and case studies. Contributions. The framework facilitates consistent communication and efficient knowledge sharing and exchange in the cloud migration domain. It also underpins a substrate for creating, standardising, maintaining, and publishing situational methods for various cloud migration scenarios.

IX

Table of Contents Chapter 1.

Introduction .................................................................................................. 1

1.1

Background to the research ............................................................................................. 1

1.2

Research Motivation and Objective ................................................................................. 2

1.3

Overview of This Thesis .................................................................................................... 4

1.4

Summary........................................................................................................................... 5

Chapter 2. 2.1

Literature Review ........................................................................................ 7

Definitions ........................................................................................................................ 7

2.1.1

Legacy Applications ...................................................................................................... 8

2.1.2

Cloud Computing .......................................................................................................... 9

2.1.3

Different Types of Legacy Application Migration to Cloud Environments ................. 12

2.1.4

Cloud Migration Process and Cloud Migration Methods ........................................... 14

2.2

Key Concerns in Cloud Migration Process ...................................................................... 15

2.2.1

Analysing Organisational Context (C1) ...................................................................... 19

2.2.2

Understanding Cloud Migration Objectives and Requirements (C2) ......................... 20

2.2.3

Proper Cloud Migration Planning (C3) ....................................................................... 22

2.2.4

Understanding Legacy Applications (C4) ................................................................... 22

2.2.5

Target Cloud Platform/Service Selection (C5) ............................................................ 23

2.2.6

Re-Architecting Legacy Applications (C6)................................................................... 25

2.2.7

Environment Configuration (C7)................................................................................. 30

2.2.8

Testing (C8) ................................................................................................................ 30

2.2.9

Tailoring (C9) .............................................................................................................. 31

2.3

A Review of Existing Cloud Migration Methods ............................................................. 32

2.3.1

Chauhan’s Method ..................................................................................................... 32

2.3.2

REMICS ....................................................................................................................... 34

2.3.3

Tran’s Method ............................................................................................................ 34

2.3.4

Cloud-RMM ................................................................................................................ 35

2.3.5

Strauch’s Method ....................................................................................................... 36

2.3.6

Zhang’s Method ......................................................................................................... 37

2.3.7

Oracle Method ........................................................................................................... 38

2.3.8

ARTIST Method ........................................................................................................... 39

2.3.9

Amazon Method ......................................................................................................... 40

X

2.3.10 2.4

Legacy-to-Cloud Migration Horseshoe .................................................................. 41

Knowledge Gaps in Current Cloud Migration Literature ............................................... 42

2.4.1

Limitations Regarding the Cloud Migration Concerns ............................................... 45

2.4.2

Lack of Tailorability Support ...................................................................................... 46

2.4.3

Lack of Integrity ......................................................................................................... 46

2.4.4

Overview of Gaps ....................................................................................................... 48

2.5

A Solution Proposal ........................................................................................................ 50

2.5.1

A Review on Theories Adopted to Understand Cloud Computing Adoption.............. 50

2.5.2

Model-Driven Software Engineering (MDSE)............................................................. 52

2.5.3

An Overview of the Proposed Framework ................................................................. 73

2.6

Summary ........................................................................................................................ 80

Chapter 3. 3.1

Research Methodology ............................................................................ 81

Research Philosophy ...................................................................................................... 81

3.1.1

Design Science Research ............................................................................................ 81

3.1.2

Research Philosophy Used in This Thesis ................................................................... 83

3.2

Research Tasks to Fulfil the Framework ........................................................................ 86

3.2.1

Development of the MLSAC Metamodel ................................................................... 87

3.2.2

Development of the MLSAC Tailoring Procedure....................................................... 87

3.2.3

Evaluation (I) of MLSAC Framework .......................................................................... 88

3.2.4

Evaluation (II) of MLSAC Framework ......................................................................... 88

3.2.5

Evaluation (III) of MLSAC Framework ........................................................................ 88

3.2.6

Using the Prototype to Perform Method Tailoring .................................................... 88

3.2.7

Getting Feedback From Domain Experts ................................................................... 89

3.3

Summary ........................................................................................................................ 89

Chapter 4. 4.1

Development of the MLSAC Framework ........................................... 91

Development of MLSAC Metamodel ............................................................................. 91

4.1.1

Step 1—Preparing Knowledge Sources for Metamodel Creation .............................. 92

4.1.2

Step 2—Extracting Constructs from the Identified Sources ....................................... 93

4.1.3

Step 3—Creating Overarching Constructs ................................................................. 96

4.1.4

Step 4—Harmonising Constructs’ Definitions............................................................ 99

4.1.5

Step 5—Organising Constructs into Phases............................................................. 102

4.1.6

Step 6—Defining Relationships among Constructs ................................................. 103

XI

4.1.7

Step 7—Defining Relationships Between Migration Types and Metamodel Constructs 105

4.1.8 4.2

Step 8—Cross-checking of the metamodel against existing methods ..................... 107 Resultant MLSAC Metamodel Version 1.0 ................................................................... 113

4.2.1

Plan Phase ................................................................................................................ 114

4.2.2

Design Phase ............................................................................................................ 115

4.2.3

Enable Phase ............................................................................................................ 116

4.2.4

Work-Product ........................................................................................................... 120

4.2.5

Metamodel Guideline ............................................................................................... 120

4.2.6

Discussion ................................................................................................................. 123

4.3

Development of MLSAC Tailoring Procedure ............................................................... 124

4.3.1

Overview on Method Tailoring Concepts ................................................................. 125

4.3.2

MLSAC Method Tailoring Procedure ........................................................................ 126

4.4

Summary....................................................................................................................... 131

Chapter 5.

Evaluation (I) of MLSAC Framework................................................ 132

5.1

Evaluation Procedure ................................................................................................... 132

5.2

Step 1—Survey Design.................................................................................................. 133

5.3

Step 2—Pilot Survey ..................................................................................................... 136

5.4

Step 3—Data Collection................................................................................................ 136

5.5

Step 4—Analysis of Collected Responses ..................................................................... 137

5.6

Describing MLSAC Metamodel ..................................................................................... 146

5.6.1

Plan Phase ................................................................................................................ 146

5.6.2

Design Phase ............................................................................................................ 149

5.6.3

Enable Phase ............................................................................................................ 152

5.7

Discussion on Using Rate and Rank in the Survey ........................................................ 156

5.8

Summary....................................................................................................................... 161

Chapter 6.

Evaluation (II) of MLSAC Framework .............................................. 162

6.1


6.2

Case Study 1: InformaIT –Sweden ................................................................................ 164

6.2.1

Case Description ....................................................................................................... 164

6.2.2

Case Analysis ............................................................................................................ 165

6.3

Case Study 2: TOAS – Finland ....................................................................................... 169

XII

6.3.1

Case Description ...................................................................................................... 169

6.3.2

Case Analysis ........................................................................................................... 170

6.4

Case Study 3: SpringTrader – United States ................................................................ 171

6.4.1

Case Description ...................................................................................................... 171

6.4.2

Data Collection and Analysis ................................................................................... 172

6.4.3

Case Analysis ........................................................................................................... 172

6.5

Evaluation Outcome .................................................................................................... 174

6.6

Summary ...................................................................................................................... 177

Chapter 7.

Evaluation (III) of MLSAC Framework .............................................179

7.1


7.2

Results .......................................................................................................................... 183

7.2.1

Overall Feedback ..................................................................................................... 183

7.2.2

Feedback Related to The Design Principles ............................................................. 185

7.3

The Refined Metamodel After All Evaluations............................................................. 188

7.3.1

Plan Phase ............................................................................................................... 190

7.3.2

Design Phase............................................................................................................ 194

7.3.3

Enable Phase............................................................................................................ 197

7.3.4

Work-Product .......................................................................................................... 202

7.3.5

Relationships............................................................................................................ 203

7.4

Summary ...................................................................................................................... 204

Chapter 8. 8.1

Prototype Implementation ..................................................................205

Description of MLSAC Prototype ................................................................................. 205

8.1.1

MLSAC Overview ...................................................................................................... 205

8.1.2

MLSAC Architecture ................................................................................................. 206

8.2

Method Tailoring ......................................................................................................... 211

8.2.1

Step 1. Setting Migration Parameters ..................................................................... 211

8.2.2

Step 2. Metamodel Instantiation ............................................................................. 212

8.2.3

Step 3. Method Configuration ................................................................................. 214

8.2.4

Step 4. Method Export ............................................................................................. 219

8.3

Comparative Analysis ................................................................................................... 221

8.4

Using the Prototype to Perform Method Tailoring...................................................... 224

8.4.1

Example 1: Instantiating and Maintaining an M1-level Migration Method ........... 225

XIII

8.4.2 8.5

Example 2: Instantiating and Maintaining a Method at M1-level and M0-levels ... 230 Getting Feedback From Domain Experts ...................................................................... 233

8.5.1

Evaluation Procedure ............................................................................................... 234

8.5.2

Results ...................................................................................................................... 236

8.6

Summary....................................................................................................................... 241

Chapter 9.

Conclusion ................................................................................................. 242

9.1

Research Summary ....................................................................................................... 242

9.2

Research Contributions ................................................................................................ 243

9.2.1

Theoretical Contributions ......................................................................................... 245

9.2.2

Contributions to Practice .......................................................................................... 247

9.3

Research Limitations .................................................................................................... 248

9.4

Future Research Directions .......................................................................................... 251

9.5

Summary....................................................................................................................... 253

Bibliography ....................................................................................................................... 254 Appendix A .......................................................................................................................... 268 Appendix B .......................................................................................................................... 280 Appendix C .......................................................................................................................... 298 Appendix D .......................................................................................................................... 333 Appendix E .......................................................................................................................... 357 Appendix F .......................................................................................................................... 361 Appendix G .......................................................................................................................... 377 Appendix H .......................................................................................................................... 379 Appendix I ........................................................................................................................... 386 Appendix J ........................................................................................................................... 394

XIV

List of Tables Table ‎2-1 Cloud service delivery models.............................................................................................. 12 Table ‎2-2 Migration types ................................................................................................................... 13 Table ‎2-3 Identified studies from literature review ............................................................................. 16 Table ‎2-4 Evaluation results of cloud migration methods (Only fully supported were counted for calculations) ............................................................................................................................... 43 Table ‎2-5 Existing techniques for metamodeling ................................................................................. 60 Table ‎2-6 Different frameworks and their design principles for metamodels ...................................... 66 Table ‎2-7 Summary of relevant research on metamodeling research in cloud computing ................... 69 Table ‎3-1 Summary of the research tasks and their objectives regarding the design principles ........... 90 Table ‎4-1 Extracted construct from studies [S3] and [S9] .................................................................... 94 Table ‎4-2 An example of extracted constructs from [S3] and [S9] ....................................................... 95 Table ‎4-3 An example of an overarching construct, named Choose Cloud Provider ............................ 98 Table ‎4-4 Constructs reconciled in Step 4 were organised into the metamodel phases ..................... 102 Table ‎4-5 Relationships among the constructs in the metamodel ..................................................... 105 Table ‎4-6 Coverage of constructs in the cloud migration methods by the metamodel ...................... 111 Table ‎4-7 Coverage of constructs in the cloud migration methods by the metamodel (continue) ..... 112 Table ‎4-8 Coverage of constructs in the cloud migration methods by the metamodel (continue) ..... 113 Table ‎4-9 Tasks and their definitions in Plan Phase ........................................................................... 114 Table ‎4-10 Tasks and their definitions in Design Phase ..................................................................... 115 Table ‎4-11 Tasks and their definitions in Enable Phase ..................................................................... 117 Table ‎4-12 Work-products and their definitions ................................................................................ 120 Table ‎4-13 Triggering of constructs in different migration types √: Mandatory, (√): Situational, × Unnecessary............................................................................................................................. 121 Table ‎4-14 List of the MLSAC metamodel constructs for inclusion in the new method ...................... 128 Table ‎5-1 Descriptive statistics of survey respondents (n = 104) ....................................................... 137 Table ‎5-2 Descriptive statistics for the constructs and the results of one sample T-Test for each construct .................................................................................................................................. 140 Table ‎5-3 Ranking constructs based on the mean.............................................................................. 141 Table ‎5-4 Details of the respondents provided justification for the importance metamodel’s constructs ................................................................................................................................................ 143 Table ‎5-5 suggested constructs by respondents ................................................................................ 145 Table ‎6-1 Profiles of case studies ...................................................................................................... 164 Table ‎6-2 Support of constructs in the migration scenarios by the metamodel ................................. 175 Table ‎6-3 list of relationships in the metamodel that were confirmed in the scenarios. √: identified -: Not identified........................................................................................................................... 177

XV

Table ‎7-1 Review timeline ................................................................................................................. 183 Table ‎7-2 Overall rates on addressing the design principles ............................................................... 184 Table ‎7-3 Identified constructs related to licensing issues from the knowledge source ..................... 185 Table ‎7-4 Identified roles involved in the migration process .............................................................. 188 Table ‎7-5 Tasks and their definitions in Plan Phase ............................................................................ 190 Table ‎7-6 Tasks and their definitions in Design Phase ........................................................................ 194 Table ‎7-7 Tasks and their definitions in Enable Phase ........................................................................ 197 Table ‎7-8 Work-products and their definitions .................................................................................. 202 Table ‎7-9 Relationships among the constructs in the metamodel ...................................................... 203 Table ‎8-1 Classes realising modelling component .............................................................................. 209 Table ‎8-2 Studies providing tool for the cloud migration ................................................................... 223 Table ‎8-3 Steps performed by each expert for evaluating the design principles ................................ 235 Table ‎8-4 experts’ feedback about the prototype regarding design principles ................................... 238

XVI

List of Figures Figure ‎2-1 Overview of the structure of this chapter ............................................................................. 7 Figure ‎2-2 Key concerns during cloud migration process ..................................................................... 19 Figure ‎2-3 Chauhan’s method [S9]....................................................................................................... 33 Figure ‎2-4 REMICS method- reproduced from [S3] .............................................................................. 34 Figure ‎2-5 Cloud-RMM migration framework [S68] ............................................................................. 36 Figure ‎2-6 Strauch’s method [S11]....................................................................................................... 37 Figure ‎2-7 Zhang’s method [S13] ......................................................................................................... 38 Figure ‎2-8 Oracle method [S25] ........................................................................................................... 39 Figure ‎2-9 ARTIST method [S64] .......................................................................................................... 40 Figure ‎2-10 Amazon process model [S71] ............................................................................................ 41 Figure ‎2-11 Legacy-to-Cloud Migration [S71] ....................................................................................... 42 Figure ‎2-12 Relationships between domain, model, and metamodel (Stahl et al., 2006) .................... 54 Figure ‎2-13 OMG four abstraction layer hierarchy (Henderson-Sellers and Bulthuis, 1998) ................ 59 Figure ‎2-14 A conceptual view of the MLSAC framework .................................................................... 79 Figure ‎2-15 The position of the MLSAC metamodel in OMG metamodeling framework, reproduced from (Karagiannis and Kühn, 2002) ............................................................................................ 79 Figure ‎3-1 Phases and research tasks for this research ........................................................................ 87 Figure ‎4-1 Steps in the development of MLSAC metamodel ................................................................ 92 Figure ‎4-2 Harmonizing the constructs .............................................................................................. 101 Figure ‎4-3 Follow Association relationship between Identify Incompatibilities and Choose Cloud Provider ................................................................................................................................... 104 Figure ‎4-4 Plan Phase ........................................................................................................................ 115 Figure ‎4-5 Design Phase .................................................................................................................... 116 Figure ‎4-6 Enable Phase .................................................................................................................... 119 Figure ‎4-7 An overview of the method tailoring procedure ............................................................... 126 Figure ‎5-1 Procedure for the evaluation (I) of MLSAC framework ..................................................... 133 Figure ‎5-2 Constructs presented in the survey highlighted with blue colour ..................................... 135 Figure ‎5-3 Design Phase after refinement by respondents’ suggestions ............................................ 146 Figure ‎5-4 Plan Phase ........................................................................................................................ 149 Figure ‎5-5 Design Phase .................................................................................................................... 152 Figure ‎5-6 Enable Phase .................................................................................................................... 156 Figure ‎5-7 Descriptive statistics for rating and ranking of constructs for n- 104 ................................ 158 Figure ‎5-8 An excerpt of the survey questions .................................................................................. 160 Figure ‎5-9 An excerpt of the survey responses .................................................................................. 161 Figure ‎6-1 Procedure for the evaluation (II) of MLSAC framework .................................................... 163

XVII

Figure ‎6-2 Apply Design Principle class after refinement through InformaIT case .............................. 169 Figure ‎6-3 Vertical and horisontal model transformations involving in the case studies .................... 174 Figure ‎7-1 The procedure for the evaluation (III) of MLSAC framework ............................................. 180 Figure ‎7-2 Design Phase after refinement through E3’s comments .................................................... 186 Figure ‎7-3 Plan Phase after refinement through E3’s comments ........................................................ 187 Figure ‎7-4 Plan Phase......................................................................................................................... 193 Figure ‎7-5 Design Phase ..................................................................................................................... 196 Figure ‎7-6 Enable Phase ..................................................................................................................... 201 Figure ‎8-1 Prototype architecture to realise MLSAC framework ........................................................ 207 Figure ‎8-2 Choosing a migration type for a target method ................................................................. 212 Figure ‎8-3 Selecting migration phases for a target method ................................................................ 212 Figure 8-4 Suggested constructs for inclusion in the created method .................................................. 214 Figure 8-5 A created method for enable phase of migration type ........................................................ 214 Figure ‎8-6 Adding a new task ............................................................................................................. 215 Figure ‎8-7 Inheritance mechanism as a way to add subclass to a construct ....................................... 216 Figure ‎8-8 Adding new supportive techniques to method tasks ......................................................... 217 Figure ‎8-9 Defining implementation techniques for resource scaling................................................. 218 Figure ‎8-10 Assigning alternative implementation techniques to the construct Enable Elasticity ...... 218 Figure ‎8-11 Specifying flow among tasks in the method .................................................................... 219 Figure ‎8-12 An excerpt of a created method described in an XML format ......................................... 220 Figure ‎8-13 Tracing procedure ........................................................................................................... 225 Figure ‎8-14 Instantiation and storing the AGIOM .............................................................................. 226 Figure ‎8-15 Activity Assess Suitability Against Business Needs in the AGIMO is stored in the Plan Phase ................................................................................................................................................. 228 Figure ‎8-16 Activity Consider Financial Impact in the AGIMO is added to the Plan Phase .................. 228 Figure ‎8-17 An excerpt of AGIMO method described in XML format ................................................. 230 Figure ‎8-18 Snapshot of the method in XML format .......................................................................... 232 Figure 8-19 Adding an implementation technique to Requirement Identification defined in the base method ..................................................................................................................................... 233 Figure ‎8-20 The procedure for getting experts’ feedback and analysis............................................... 234 Figure ‎9-1 DSR Knowledge Contribution Framework (Gregor and Hevner, 2013) ............................... 244

XVIII

Chapter 1. Introduction

Chapter 1.

Introduction

Migration is a sign of protest - African Proverb

1.1

Background to the research

Many enterprise software applications supporting IT functions are characterised by the need for high computing capability, reducing the cost of maintenance and upgrading, efficient resource utilisation, and less environmental impact and electrical energy consumption (Armbrust et al., 2010, Buyya et al., 2008, Koçak et al., 2013). Cloud computing has received significant attention to address such requirements through offering a wide range of services which are universally accessible, dynamically acquirable and releasable, and payable on the basis of service usage amount. It is estimated that the global cloud computing market will grow from $40.7 billion in 2011 to $241 billion in 2020 (Ried S, 2011). Given advantages that cloud services offer, many IT-based organisations are currently moving their legacy assets to cloud environments. Migrating large-scale legacy enterprise applications is a critical task. Legacy applications often predate cloud computing and thus have been developed without taking into account the unique characteristics of cloud environments such as elasticity, efficient cloud resource usage, multi-tenancy, and interoperability (Section 2.2). Such characteristics raise new challenges that need to be adequately addressed when moving legacy applications to the cloud. Despite the abundance of techniques and tools for exploiting cloud services, the current state of research on designing methods (process models) attuned with moving legacy applications to the cloud is far from desirable. The methodological support for such a transition is poorly understood and little, if any, common understanding of it exists in the current literature. This research, aimed at alleviating the problems afflicting methodological aspects of cloud migration, utilises the notion of Model-Driven Software Engineering (MDSE), as a theoretical lens, through which a framework is developed. The proposed framework includes an integrated generic reference process

1

Chapter 1. Introduction model and a tailoring procedure for creating, configuring, and sharing concrete bespoke migration methods through reuse and enhancement of the reference model. This chapter is structured as follows: the motivations and objective of this research are discussed in Section 1.2. This is followed by an outline of the organisation of the remaining chapters in Section 1.3. This chapter concludes in Section 1.4.

1.2

Research Motivation and Objective

This research has been motivated by a number of problems and issues that have been reported in the cloud computing literature. This section provides discussion of the problem areas emphasising why a comprehensive solution is required. Although trivial migration projects may be manageable in an ad-hoc manner, adopting methodological approaches becomes important when large-scale and interconnected applications supporting core business processes are moved to the cloud. A wellstructured method can aid developers to carry out an effective and safe application migration, instead of struggling to understand what and how to carry out such a transition, which may latter result in poor and erroneous migration and maintenance overheads. A methodological approach can be acclaimed as a promising means for tackling cloud migration complexities and moving from an ad-hoc cloud migration to structured and step-by-step quality methods. In this spirit, previous research acknowledges that moving legacy applications to the cloud needs to be conducted, anticipated, and viewed from the methodological perspective. Laszewski and Nauduri, mention: Like any software development project, migration projects require careful planning and good methodology to ensure successful execution (Laszewski and Nauduri, 2011). A similar recommendation can be found in the final report of REMICS method (REuse and Migration of legacy applications to Interoperable Cloud Services), which is part of a research project supported by the European Commission and focuses on a methodological support for moving applications to cloud platforms (Benguria et al., 2013). The report pinpoints “In the beginning it [legacy migration] was motivated by the lack of documentation, but in the last years it has been motivated by adaptation to new technologies. Each new technology has required new and renewed approaches and technologies to address the migration process in a more effective way”(p.15).

2

Chapter 1. Introduction Research pertaining to the methodical cloud adoption has largely been ignored in the current literature on the cloud computing. Mahmood (Z.Mahmood, 2013) presents a review of developments and practical guidance on methods, technologies, and frameworks for the emerging cloud computing paradigm. He points out: “Although the technologies underlying the cloud paradigm have been in existence for some time, the frameworks and methodologies for construction, deployment and delivery of cloud services and environments are in the process of being further developed and refined” (p.viii). The importance of developing cloud migration methods which enable managers to migrate legacy applications to the cloud has been well recognized by the survey paper of a wide range of studies of the cloud migration (Jamshidi et al., 2013). They conclude: “A migration framework defines a systematic process to perform the migration while evidences define concrete tasks, methods and techniques. Such a concrete framework would constitute an important contribution towards a systematic migration to the cloud” (p.154). The above examples and other literature review papers such as (Zhao and Zhou, 2014, da Silva and Lucredio, 2012) underline the fact that the status quo of the field shows potential for improvement via addressing the methodological aspect of the cloud migration. The above arguments are further corroborated in Section 2.3 where a detailed review of the dozen existing migration methods reveals the existence of a knowledge gap in the current literature. This includes the lack of a consolidated process model of the cloud migration and a support for creating customised methods, which fit given cloud migration scenarios. Furthermore, there is no domain-independent and empirically evaluated research on what is entailed in a seamless migration of working applications to cloud environments. Motivated by the benefits of cloud computing to enterprise applications and the discussion outlined above, this research aims at developing a consolidated framework to provide a methodological support for cloud migration. To this end, this research adopts MSDE, which is a well-known approach in information systems (IS) and software engineering (SE) for developing domain-specific languages and knowledge reuse (Section 2.5.2). The proposed framework is populated through an extensive reuse and

3

Chapter 1. Introduction harmonising of existing cloud migration literature and iterative refinement and improvement based on feedback from domain experts. Thus, the objective of this research is formulated as follows: To contribute to the field of cloud computing by proposing a framework to provide a generic reference process model including essential domain constructs for the incorporation into cloud migration process, to support creating, configuring, and sharing bespoke methods for given cloud migration scenarios.

1.3

Overview of This Thesis

The structure of this dissertation comprises nine chapters, including this introductory chapter providing an overview of this research. The objectives of the remaining chapters are as follows. Chapter 2 provides background information about cloud-related terminologies such as legacy application, cloud computing, cloud migration types, a list of key concerns in moving applications to cloud environments, and then presents an explanation of existing methods addressing this transition. An evaluation of existing methods with respect to the key concerns of cloud migration is presented and knowledge gaps are identified. Then, the chapter turns to a solution space addressing the gaps, following with reviewing the literature on MDSE, metamodeling, and research related. Finally, based on design principles grounded from the metamodeling literature, an architecture framework is presented. Chapter 3 describes and justifies the design science research as an overall research paradigm for carrying out this research. The chapter presents a research plan and related tasks tailored for conducting this research. Chapter 4 reports on the design process of the proposed framework components, which includes two tasks. The first task develops an integrated and generic process model derived from existing cloud migration literature. This comprised preparing a knowledge source of published studies for moving applications to the cloud, extracting and shortlisting a collection of constructs from these sources, reconciliation and harmonisation of construct definitions, organising them into phases, defining relationships among constructs, defining relationships between constructs and migration types, and finally

4

Chapter 1. Introduction cross-checking the resultant process model with existing cloud migration methods. The second task in this chapter develops a generic procedure for customising the process model developed in the first task. Chapter 5 presents experts’ feedback, gathered through a Web-based survey, on the framework. It includes the respondents’ perceived importance of the constructs defined in the process model, areas suggested for improvement, and comment on the framework’s completeness and soundness. Chapter 6 evaluates the framework through case studies in which the framework is used to instantiate domain specific cloud migration models. The analysis results of the case studies are presented along with the list of refinements made to the framework. Chapter 7 reports on the execution and results of an assessment of the refined framework by a panel of experts in the cloud computing field. Respondents reviewed the framework and provided qualitative feedback on completeness and soundness, understandability of constructs, validity of definitions and relationships, and suggestions for improvement. Chapter 8 describes the implementation of the framework, the prototype software which enables to use and tailor migration methods through reusing, configuring, and enhancing the framework. The prototype is used for the final evaluation of the framework. The chapter also presents the comparative analysis of the prototype against tools related to cloud migration, experts’ opinions about completeness and soundness, understandability of constructs, validity of definitions, and the capability of the prototype, as the final product of this research, in creating, configuring, and maintaining situational cloud migration methods. Chapter 9 summarises the research, research implications, research limitations, and draws directions for future work.

1.4

Summary

This chapter has sought to present a landscape of the proposed research and its position in the cloud computing literature. Accordingly, the chapter briefly introduce the gap in the literature and importance of having a solution to address it. The chapter also showed an outline of the remaining chapters.

5

Chapter 1. Introduction

6

Chapter 2. Literature Review

Chapter 2.

Literature Review

Research is to see what everybody else has seen, and to think what nobody else has thought - Albert Szent-Gyorgyi This chapter provides a background to the foundational concepts used in this research and is organised as follows. Section 2.1 presents definitions of legacy applications, terminologies related to the cloud computing, cloud migration variants, and the cloud migration process are presented. In Section 2.2, the chapter discusses a set of key concerns related to a typical legacy to cloud migration process. Section 2.3 reviews existing methods pertaining to legacy migration to cloud environments. Observations from these methods and current knowledge gaps in the current literature are detailed in Section 2.4. The chapter then turns to the solution space in Section 2.5 by reviewing theories and approaches to understanding the nature of the cloud migration (Section 2.5.1), introducing the model driven software engineering (Section2.5 2.5.2), and proposing a solution framework to address the identified gaps (Section 2.5.3). Section 2.6 concludes this chapter. Figure 2-1 depicts an overview of the structure of this chapter.

Figure ‎2-1 Overview of the structure of this chapter

2.1

Definitions

The purpose of this section is to clarify the concepts related to this research, including

7


legacy applications, cloud computing, different types of cloud migration, cloud migration process, and methods supporting legacy migration to cloud environments. 2.1.1 Legacy Applications The term legacy firstly appeared in software engineering in 1990 meaning of, relating to, or being a previous or outdated computer system (Merriam-Webster, 2013). Many definitions can be found for the term legacy applications. One of the earliest definitions, obtained from (Bennett, 1995), is the following: “large software systems that we don't know how to cope with but they are vital to our organisation” (p.19). Similarly, Stonbraker (Brodie and Stonebraker, 1995) mentions “any system that significantly resists modification and evolution” (p.1). Sneed (Sneed, 2006) explains the term as “information systems that have been in use for years” (p.1). Stone (Stone, 2001) distinguishes applications as those that are not Internet-dependent. Dedeke (Dedeke, 2012) defines them as “an aggregate package of software and hardware solutions whose languages, standards, codes, and technologies belong to a prior generation or era of innovation” (p.38). Holland (Holland and Light, 1999) explicitly mentions that “legacy applications encapsulate the existing business processes, organization structure, culture, and information technology” (p.31). Likewise, in (Bisbal et al., 1999) legacy applications have been characterised “as massive, long-term business investment, and crucial to an organization” (p.103). They are one of the major components of IT-based organisations, represent business services and the knowledge of organisations, and can provide a significant competitive advantage with a positive return and contribution to the organisation’s revenue and growth (Bennett, 1995, Sneed, 1995, Erlikh, 2000). A common impression provided in all these definitions is the worthiness of legacy applications. From the technical point of view, the term legacy application is often co-located with a very old generation of technologies, standards, protocols and programming languages such as FORTRAN, COBOL, or C and old indexed database and file system

8


technologies. They are associated with old mainframe applications that are responsible for enormous transaction processing and supporting thousands of users and concurrently accessing numerous resources. Nevertheless, modern client-server applications, which have been developed using the latest technologies available in the marketplace such as .Net Framework and J2EE, and currently do not satisfy new business requirements are also considered as legacy applications (Khadka et al., 2013, Sneed, 2006). A common architecture style of enterprise applications is 3-layered (or 3-tierd), comprising a user interface layer receiving user requests and handles them, a business logic layer providing application functionalities, and a data layer for manipulating data. Each layer may have multiple components, which are deployable on different servers and able to collaborate with one another. The focus here is research studies addressing moving legacy layers to cloud environments. 2.1.2 Cloud Computing There are many definitions floating around for the term cloud computing, e.g. (Armbrust et al., 2010, Motahari-Nezhad, 2009, Grance, 2009) and yet the term is still somewhat ambiguous, fluid, and multifaceted that may be subjectively interpreted and applied by academia and practitioners. Among several definitions in the literature, the US National Institute of Standards and Technology (NIST) (Grance, 2009) provides a definition, which is commonly agreed to be complete and is well-cited definition of the cloud computing (Sriram and Khajeh-Hosseini, 2010, Motahari-Nezhad, 2009, KhajehHosseini et al., 2010). NIST (Grance, 2009) describes the cloud computing as: “A model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” (p.2). The above definition encompasses several essential features:  On-demand self-service. A consumer with an instantaneous need at a particular time can avail services (such as CPU time, network storage, and software use) automatically with little interactions with providers of these services (Grance, 2009).

9

Chapter 2. Literature Review  Service-oriented. Service providers use a service-driven approach to offer their services according to the SLA negotiated with customers. SLA assurance is an important aspect of every service provider (Grance, 2009).  Broad network access. Cloud services are deployed on a private network (private cloud) or a public network (public cloud) and available for use by various platforms such as mobile phones, laptops, and PDAs (Grance, 2009).  Shared resource pooling. Cloud service providers offer a pool of resource that can be used by multiple service consumers at the same time. Such a harness for service allocation brings more flexibility for service providers in order to manage their own service usage and operating costs (Zhang et al., 2010, Grance, 2009).  Rapid elasticity. Computing resources that are offered to service consumers are temporal rather than durable. From a service consumer perspective, service provisioning appears infinite and a consumer’s need for more service can be scaled up on the fly (Grance, 2009).  Multi-tenancy. It enables economizing the utilisation of services, as multiple customers, share the same services that are offered by a provider. Multi-tenancy may raise issues such as addressing performance and security (Rimal et al., 2009, Grance, 2009).  Measured Service. Since services are pooled and shared by multiple consumers or tenants, service providers can measure service usage through different policies and metering mechanisms (Grance, 2009). Cloud services are offered through de-facto standards such as Web-Service technology (Christensen et al., 2001). The main difference among cloud services is related to what is offered to a service consumer such as software, hardware, platform, infrastructure, and data (Hoefer and Karagiannis, 2010, Foster et al., 2008). In this regard, the NIST defines a category of cloud service delivery models as follows (see Table 2-1):  Software as a Service (SaaS) or on-demand software enables service consumers to use software applications on a pay-per-use model. A service provider is responsible for maintaining the software and its underlying hardware (Grance, 2009). Service providers release the software on their hosting environment and make it publically available to customers typically through the Internet. Service consumers do not need to install the software through a Web browser or PDA. Service consumer has limited

10


control over the services. It is the responsibility of the service provider to meet commonly expected quality standards such as performance, security, availability, and disaster recovery. A big advantage of SaaS is the potential to reduce IT costs by outsourcing hardware and software maintenance to the SaaS provider. Examples of SaaS include SalesForce.com, Microsoft Office 365, Google Apps, Google Mail, Google Docs, Dropbox, and SkyDrive.  Platform as a Service (PaaS) supports the full software development lifecycle so that service providers/consumers can build cloud services (e.g. SaaS) directly via the PaaS (Grance, 2009). In comparison with the SaaS delivery model, PaaS provides a comprehensive development platform including a programming environment, tools, and configuration management, and hosting environment for both under-developed cloud services and completed ones. Well-known examples of PaaS are Google AppEngine, Microsoft Azure, and Manjrasoft Aneka.  Infrastructure as a Service (IaaS) or Hardware as a Service (HaaS) refers to delivering IT infrastructures such as processing, storage, networks, and other fundamental computing resources to consumers (Grance, 2009). The customer acquires and pays by demand for services. Virtualization is a common operationalisation way which is used in IaaS cloud in order to integrate/decompose physical resources to meet growing or shrinking resource demand from service consumers (Fox et al., 2009). Examples of IaaS are Amazon EC2, GoGrid, IBM SmartCloud, and Nirvanix. Another classiﬁcation for cloud services is defined from a service ownership perspective. When cloud services are shared among different consumers, they are referred to as a public cloud (Fox et al., 2009, Höfer and Karagiannis, 2011). Such services are hosted and maintained by their owners and consumers can access, use, and pay for these services under a predefined contract for what they use. For instance, Amazon, Google App Engine, and Azure are public clouds. When the security of an organisation’s assets is a concern, a private cloud comes into play where it allows organisations build their own infrastructure and deploy their data and services on it (Fox et al., 2009) which may be hosted and maintained either by the

11


organisation itself or by a third party. A private cloud allows organisations to take maximum benefit of elasticity and virtualisation without having to share physical infrastructure with other organisations. However, compared to the public cloud, an initial investment is needed in making infrastructure and services. A combination of these models, known as a hybrid cloud (Höfer and Karagiannis, 2011, Fox et al., 2009, Grance, 2009), is also practicable where some components of an application run in a public cloud and some other components run in a private cloud. Table ‎2-1 Cloud service delivery models

-

Category SaaS PaaS

IaaS

Feature Consumers are offered applications that are publically accessible. Consumers are offered a platform for building and host applications in the cloud.

Customers are offered wide ranges of computational resources on top of which they can deploy their applications.

Product type Web applications and services Programming environments and APIs, tools, and configuration management Virtual machines -

Sample Products SalesForce.com, Google documents, and Google mail Google AppEngine, Microsoft Azure, and Manjrasoft Aneka Amazon EC2 and GoGrid

2.1.3 Different Types of Legacy Application Migration to Cloud Environments Taking into account the cloud service delivery models IaaS, PaaS, and SaaS (Section 2.1.2), one can see there are a few possibilities to enable legacy applications to utilise cloud services. In this research, they are referred to as the variant types of legacy to the cloud migration. Synthesised from the classifications proposed by (Andrikopoulos et al., 2013, Jamshidi et al., 2013), Table 2-2 presents definitions and examples of migration variants. For reasons such as issues security, performance variability of the cloud services, and network latency, organisations may choose a hybrid migration where some legacy components are migrated to the cloud and other components are kept in the organisation’s local network and cloud services are offered to them. The hybrid migration gives more flexibility for making a decision on the right balance between privacy concerns and cloud advantages such as performance and cost savings (Hajjat et

12


al., 2010). Table ‎2-2 Migration types

Migration

Symbol

Definition Deploying the business logic layer of legacy application (e.g. WS-BPEL), which offer independent and reusable functionalities, in the cloud infrastructure by applying the

Type I

delivery model IaaS. The data layer is kept in local organisational network. Deploying an image-processing

component

of

an

application in EC2, is an example of this migration type. Re-engineering to SaaS or replacing some components or whole legacy application stack Type II

with an available and fully tested SaaS. The Salesforce CRM application is a typical example of SaaS, which can be integrated with other applications via its interfaces. Deploying the legacy database in a cloud data store provider through IaaS delivery service model. In this migration type, the components related to business logic layer are kept in

Type III

local organisation network and the database is deployed in a cloud data store such as Amazon

Simple

Storage

Service

(S3),

Amazon Elastic Block Store (EBS), Dropbox, Zip Cloud, and Just Cloud. Converting the data, schema, and modifying the data layer of legacy data layer to a cloud Type IV

database solution provider such as Amazon SimpleDB, Google App Engine data store, or Google Cloud SQL. Deploying the whole application stack in the

Type V

cloud infrastructure via service delivery model IaaS. The application is encapsulated

13


into a single Virtual Machine (VM) and then is run in cloud infrastructure. Hosting of a Web application and its Web server as a VM on EC2 is an example of such a migration variant.

2.1.4 Cloud Migration Process and Cloud Migration Methods Moving applications to the cloud implies that an organisation has already in place existing workable software applications earmarked to take advantage of cloud services. There are a few definitions for the cloud migration process. (Chauhan and Babar, 2012) refers to it as a specific form of software reengineering through which legacy codes are modified to be able to interact with and utilise cloud services. A second definition views the cloud migration process as a set of architectural modifications in legacy applications to make them cloud compliant (Andrikopoulos et al., 2013). Furthermore, Kwon et al. propose the term cloud refactoring in which code transformation mechanisms are used as means to integrate legacy components with cloud services (Kwon and Tilevich, 2014). A broader definition, which covers both technical and non-technical aspects of the cloud migration, suggested by (Pahl et al., 2013) as: “A cloud migration process is a set of migration activities carried to support an end-to-end cloud migration. Cloud migration processes define a comprehensive perspective, capturing business and technical concerns. Stakeholders with different backgrounds are involved” (p.87). In the contexts of IS and software engineering, a high-level definition of an ISD method (or method for short) is defined in (Gonzalez-Perez and Henderson-Sellers, 2008) as a systematic way of doing things in a particular discipline (p.4)1. Another definition, but more precise, suggested by Avison and Fitzgerald (Avison and Fitzgerald, 2003) is a “recommended

collection

of

phases,

procedures,

rules,

techniques,

tools,

documentation, management and training used to develop a system” (p.27). A method

1

The terms “methodology” and “method” are sometimes used interchangeably in IS and software engineering literature. For consistency, this research uses the term method.

14


organises the coordination of development team members, the integration of project activities, and specifies when certain activities, which contains sequence and input/output artefacts, should be carried out. Given the above definitions, one can envisage a cloud migration method as an extension to traditional or in-house methods to enhance their capabilities to support moving legacy applications to the cloud. A cloud migration method can be viewed as a process model guiding developers in conducting one or more particular migration types (Section 2.1.3) and ignoring others. A review of such methods is presented in Section 2.3.

2.2

Key Concerns in Cloud Migration Process

It is suggested that since cloud environments are not sufficiently mature or secure, some applications such as safety critical ones (e.g. military, aviation, and aerospace) might not directly benefit from cloud services (Marston et al., 2011, Andrikopoulos et al., 2013). Other applications such as business enterprise applications can be enabled to utilise cloud services. The migration process of the latter applications still involves some concerns which need to be adequately addressed. Drawing on the cloud migration literature, a set of key concerns relevant to the process of legacy migration to cloud environments was synthesised. In doing so, recommendations for conducting a SLR (Systematic Literature Review) introduced in (Kitchenham et al., 2009) was undertaken to answer the following research question What key concerns are considered in the cloud migration literature and should be addressed during the process of legacy migration to cloud environments? Accordingly, the review recommended steps (i) defining search strings, (ii) selecting study sources, (iii) defining study selection criteria, (iv) conducting the review, and (v) extracting demographic data. As the research on the cloud migration has received attention from both academia and industry alike, both groups were covered. This research selected only studies and excluding those without a clear evaluation, short papers, or prefaces. The corresponding

15


steps of SLR are shown in Appendix A. Seventy-five papers were identified (see Table 2-3). Note that, each study has a unique identifier starting with ‘S’ used throughout the rest of this thesis. Full demographic information of the papers is presented in Appendix A. Table ‎2-3 Identified studies from literature review

Study ID [S1] [S2] [S3] [S4] [S5] [S6] [S7] [S8] [S9] [S10] [S11] [S12] [S13] [S14] [S15] [S16] [S17] [S18] [S19] [S20] [S21] [S22] [S23]

Authors and title Krasteva, I., Stavru, S., et al., “Agile Model-Driven Modernisation to the Service Cloud” Beserra, P. V., Camara, A., et al, “Cloudstep: A step-by-step decision process to support legacy application migration to the cloud” Mohagheghi, P., “Software Engineering Challenges for Migration to the Service Cloud Paradigm: Ongoing Work in the REMICS Project” Conway, G. and Curry, E., “The IVI Cloud Computing Life Cycle” Khajeh-Hosseini, A., Greenwood, D., et al, “Cloud migration: A case study of migrating an enterprise it system to iaas” Tran, V., Keung, J., et al, “Application migration to cloud: a taxonomy of critical factors” Khajeh‐Hosseini, A., Greenwood, D., et al, “The cloud adoption toolkit: supporting cloud adoption decisions in the enterprise” Kundra, V., “Federal cloud computing strategy” Chauhan, M. A. and Babar, M. A, “Towards Process Support for Migrating Applications to Cloud Computing” Strauch, S., Andrikopoulos, V., et al. “Migrating eScience Applications to the Cloud: Methodology and Evaluation” Strauch, S., Andrikopoulos, V., et al., “Migrating Enterprise Applications to the Cloud: Methodology and Evaluation” Leymann, F., Fehiling, C., et al., “Moving applications to the cloud: An approach based on application model enrichment” Zhang, W., Berre, A.,J., et al., “Migrating legacy applications to the service Cloud” Frey, S., Wilhelm, H., et al., “Automatic conformance checking for migrating software systems to cloud infrastructures and platforms” Miranda, J., Guill´en, J., et al., “Assisting Cloud Service Migration Using Software Adaptation Techniques” Fehling, C., L.Frank, et al, “Service Migration Patterns--Decision Support and Best Practices for the Migration of Existing Service-Based Applications to Cloud Environments” Tak, B. C., Bhuvan, U., et al., “To move or not to move: the economics of cloud computing” Guillén, J., Javier, M., et al., “A service-oriented framework for developing cross cloud migratable software” Ardagna, D., Di Nitto, E., et al., “Modaclouds: A model-driven approach for the design and execution of applications on multiple clouds” Hajjat, M., Sun, X., et al. “Cloudward bound: planning for beneficial migration of enterprise applications to the cloud” Moens, H., Famaey, J., et al., “Design and evaluation of a hierarchical application placement algorithm in large scale clouds” SUN, K., Li, Y., “Effort Estimation in Cloud Migration Process” Rabetski, P. and Schneider, G. “Migration of an On-Premise Application to the Cloud: Experience Report”

16


[S24] [S25] [S26] [S27] [S28] [S29] [S30] [S31] [S32] [S33] [S34] [S35] [S36] [S37] [S38] [S39] [S40] [S41] [S42] [S43] [S44] [S45] [S46] [S47] [S48] [S49] [S50] [S51] [S52]

Pahl, C., Xiong, H., et al., “A Comparison of On-Premise to Cloud Migration Approaches” Laszewski, T. and Nauduri, P., “Migrating to the Cloud: Oracle Client/Server Modernisation” Guo, X., “Evaluation of a Methodology for Migration of the Database Layer to the Cloud based on an eScience Case Study” Ahmad, A., and Babar. M.A, “A framework for architecture-driven migration of legacy systems to cloud-enabled software” Ridha, G, Saida, K., et al., “OPENICRA: Towards A Generic Model for Automatic Deployment of Applications in the Cloud Computing” Council, C. S. C., “Migration applications to public Cloud Services: roadmap for success” Menzel, M., Schönherr, M., et al., “(MC2) 2 : A Generic Decision-Making Framework and its Application to Cloud Computing” Quang H. V., and Asal, R., “Legacy Application Migration to the Cloud: Practicability and Methodology” Huru, H.A., “MILAS: ModernIsing Legtacy Applications towards Service Oriented Architecture (SOA) and Software as a Service (SaaS)” Benguria, G., Elvesæter, B., Ilieva, S., “REuse and Migration of legacy applications to Interoperable Cloud Services” Tang,K., Zhang J.M, Feng, C.H, “Application Centric Lifecycle Framework in Cloud” Bezemer, C. P., Zaidman, A., et al., “Enabling multi-tenancy: An industrial experience report” Guo, C. J., Sun, W., et al., “A framework for native multi-tenancy application development and management” Mietzner, R., Unger, T., et al., “Cafe: A generic configurable customisable composite cloud application framework” Strauch, S., Andrikopoulos, V., et al., “Transparent Access to Relational Databases in the Cloud Using a Multi-Tenant ESB” Marimuthu, C., Chandra Sekaran, K., “Software Development for Cloud: An Experiential Study” Anstett, T., Leymann, F., et al., “Towards BPEL in the Cloud: Exploiting Different Delivery Models for the Execution of Business Processes” Varia, J., “Architecting for the cloud: Best practices” Bessani, A., Correia, M., et al., “DepSky: dependable and secure storage in a cloud-ofclouds” Curino, C., Jones, E.P.C., et al., “Relational cloud: A database-as-a-service for the cloud” Binz, T., Leymann, F., et al. , “CMotion: A framework for migration of applications into and between clouds” Fehling, C., Leymann, F., et al., “Pattern-based development and management of cloud applications” Chauhan, M. A. and Babar, M. A., “Migrating Service-Oriented System to Cloud Computing: An Experience Report” Zagarese, Q., Canfora, G., et al., “Enabling advanced loading strategies for data intensive web services” Cisco Systems, “Planning the Migration of Enterprise Applications to the Cloud” Duplyakin, D., Marshall, P., et al., “Rebalancing in a multi-cloud environment” Babar, M.A, Chauhan, M.A., “A Tale of Migration to Cloud Computing for Sharing Experiences and Observations” Pahl, C. and Xiong, H., “Migration to PaaS clouds-Migration process and architectural concerns” Saleh,E., Shaabani,N., Meinel, C., “A Framework for Migrating Traditional Web

17


[S53] [S54] [S55] [S56] [S57] [S58] [S59] [S60] [S61] [S62] [S63] [S64] [S65] [S66] [S67] [S68] [S69] [S70] [S71] [S72] [S73] [S74] [S75]

Applications into Multi-Tenant SaaS” Karampaglis,Z., Mentis,A., Rafailidis,F., Tsolakidis, P., Ampatzoglou, A., “Secure Migration of Legacy Applications to the Web” Ilieva,S., Krasteva, I., Benguria, G., Elvesæter, B., “Enhance your Model-driven Modernisation Process with Agile Practices” Bahga, A., Madisetti, V.K., “Rapid Prototyping of Multitier Cloud-Based Services and Systems” Logicalis, “Logicalis, Migrating to the Cloud – A Logicalis How to Guide” Lindner, M.A., McDonald, F., et al., “Understanding Cloud Requirements - A Supply Chain Lifecycle Approach” Zhu.Y., “A Platform for Changing Legacy Application to Multi-tenant Model” Zhou, H., Yang, H., et al., “An Ontology-Based Approach to Reengineering Enterprise Software for Cloud Computing” Frey.S., Hasselbring, W., “An Extensible Architecture for Detecting Violations of a Cloud Environment’s Constraints During Legacy Software System Migration” Frey, S. and Hasselbring, W., “The cloudmig approach: Model-based migration of software systems to cloud-optimised applications” Banerjee, J., “Moving to the cloud: Workload migration techniques and approaches” Nussbaumer, N., Liu, X., “Cloud Migration for SMEs in a Service Oriented Approach” Menychtas, A., Santzaridou,C., et al., “ARTIST Methodology and Framework: A novel approach for the migration of legacy software on the Cloud” Andrikopoulos, V., Binz, T., et al., “How to Adapt Applications for the Cloud Environment” S., Rajaraajeswari, R., Pethuru, “Cloud Application Modernisation and Migration Methodology” Duarte and Silva 2013, “Cloud Maturity Model” Jamshidi, P., Ahmad, A., et al., “Cloud Migration Research: A Systematic Review” La, H., J., Kim, S., D., 2009, “A systematic process for developing high quality saas cloud services. Cloud Computing” Meiländer, D., Bucchiarone, A., et al., “Using a lifecycle model for developing and executing real-time online applications on clouds” Varia, J., “Migrating Your Existing Application to the AWS Cloud. A Phase-Driven Approach to Cloud Migration” Wu, J., Teregowda, P., et al., “Migrating a Digital Library to a Private Cloud” Betts, D., Homer, A., et al., “Moving Applications to the Cloud on Microsoft Windows Azure” Maenhaut, P., Moens, H., “Migrating legacy software to the cloud: approach and verification by means of two medical software use cases” Kwok, T., “A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application”

The synthesising of key concerns of the studies in Table 2-3 has been based on the procedure, explained in Section 4.1, including the following steps: (i) Extracting constructs from the Identified Studies, (ii) Creating Overarching Constructs, (iii) Harmonizing Constructs’ Definitions, (iv) Organising Constructs into Phases, and (v) Defining Relationships among Constructs. Figure 2-2 shows the key concerns that were subsequently identified including: (i) Analysing Organisational Context, (ii) Understanding Cloud Migration Objectives and

18


Requirements, (iii) Proper Cloud Migration Planning, (iv) Understanding Legacy Applications, (v) Target Cloud Platform/Service Selection, (vi) Re-Architecting Legacy Applications, (vii) Environment Configuration, (viii) Testing, and (ix) Tailoring. These concerns need to be properly addressed by IT developers during migration to the cloud. The following subsections 2.1.1 to 2.2.9 explain each concern, denoted by letter C and a unique number. In addition to the citation to the identified studies, studies related to the general literature on cloud computing have been also used in the following sections.

Figure ‎2-2 Key concerns during cloud migration process

2.2.1 Analysing Organisational Context (C1) A transition to the cloud is not merely a technological improvement of existing legacy applications but also a substantial change in the way they hereinafter operate, provide IT functions, and are maintained. An important consideration before starting a migration

19


project is to assess the feasibility and business value of cloud adoption to empower legacy applications. According to Khaje-Hosseinin’s experience in applying the migration type I, there is a risk of a structural change and department downsizing in ITbased organisations since some responsibilities related to the maintenance and upgrading of legacy applications will be relegated to cloud providers [S5]. IT staff associated with these applications might also be affected or perhaps lose their influence. The literature defines the following areas of concern, that should be taken into account at the early stage of the migration process: “user resistance and the loss of governance” [S2], “dependency on legacy application” [S27], “the risk of unauthorised access” [S71], “legal restriction”, “the physical location of IT resources” [S5], “energy consumption, variation on responsibilities, technical suitability” [S7], “impact on organisational and daily activities” [S4], “the type of legacy application” [S29], “required efforts and migration cost” [S27], “scalability (workload fluctuation) in the cloud” [S68], and “financial suitability” [S64]. 2.2.2 Understanding Cloud Migration Objectives and Requirements (C2) Despite the fact that common requirement engineering techniques such as interview, prototyping, and workshop, referred in software engineering literature are still applicable in the context of cloud migration, some studies have added a focus on analysing requirements such as “expected elasticity and scalability of application in the cloud” [S24], “computing requirements of legacies” [S25], “inter-operability across different cloud platforms” [S24], “security and regulatory” [S29], and “storage space requirements for the application in the cloud” [S72]. 2.2.2.1 Legal and political issues

While the cloud computing technology is a strategic weapon for national competitiveness and economic growth of domestic IT-based organisations, there is a need for a deep understanding of the influence of cloud computing on internal legal and political considerations of organisations regarding data security (Gupta, 2012). Laws

20


and regulations defined by government, industry, or organisations should be followed when using cloud services, in particular, the security and transfer of data across geographical areas. In the cloud computing model, servers operating across distributed networks. The data stored on servers may be either accessed accidentally by the authorities seeking another organisation’s data or vulnerable to security risks such as terrorism or cyber-attack. However, responsibilities around legal and political issues fall inside a grey area (Zissis and Lekkas, 2012, Kshetri, 2013). Some argue that organisations rather than cloud service providers are legally responsible for customer data because the later are not supposed to be involved in legal aspects of the organisation. In contrast, others may argue that service providers are responsible for satisfying essential privacy concerns (Wittow and Buller, 2010, Wilshusen, 2010). The dynamism between cloud service consumers and providers can change responsibilities of both parties. Hence, when organisations are deciding on cloud migration, they may find that legal and political issues are barriers to the adoption. Legal and political issues around an organisation’ data may lead to an increased level of security assurance offered by cloud service providers seeking to be eligible to organisations, industry, or government sectors (Nelson, 2009). In some cases, organisations need to align their legal systems and enforcement mechanisms to allow for the cloud migration. Organisations have a common concern about the exact location where their application components will be hosted, executed, and data processed (Ristenpart et al., 2009, Gupta, 2012). In the cloud, there is no longer an assumption about a region or location that an application and its data are hosted; they may move between different cloud servers based on network traffic, server workload, and load balancing mechanisms defined by servers or service consumers. An application owner might not be able to determine the exact location of the code execution. While cloud providers are targets for malicious cyber-attack, application security can be compromised (Hay et al., 2011). As a countermeasure against security risks, developers need to provide mechanisms in the application to ensure the security of sensitive data within legal boundaries, specifically, those components that may be relocated between servers in different geographical areas, for migration types I, II, III, IV, and V.

21


2.2.3 Proper Cloud Migration Planning (C3) Once project stakeholders accept cloud migration as a feasible decision, a plan guiding the rest of the migration process is required. The identified studies vary in recommending factors that should be considered in the planning phase. Strauch’s method [S10] defines planning as a set of actions for resolving potential incompatibilities between legacy components and target cloud database solutions, without modifying the application business logic. Additionally, Pahl et al. take into account parameters, such as the capabilities of a cloud service provider, addressing contract with cloud service providers, the distribution and capabilities of the migration development team (e.g. technology, skills, and tools), and defining metrics and milestones [S24]. According to [S66], information about legacy applications is an important source for migration planning. For instance, if applications X and Y are using the same database server, a possible migration plan would be a combined move or splitting the dependencies. Furthermore, in the method, Legacy-to-Cloud Migration Horseshoe [S27], authors incorporate the influence of cloud provider selection and the choice of a migration type as the main factors for developing a migration plan. Finally, defining a proper rollback plan, i.e., switching to a previous version of the application at any stages of the migration process, will reduce risks to an organisation’s business, as [S4] highlights “the option to roll back to an in-house version at any stage significantly reduced the risk and exposure to the business. Organisations that experienced difficulties in the transition to cloud computing missed vital steps in their planning”. Wu et al. recommend defining Backward Availability for critical migration projects in case a new cloud application fails [S72]. 2.2.4 Understanding Legacy Applications (C4) It is common that knowledge about legacy applications is outdated, imperfect, or undocumented. Identifying any characteristics of legacy applications that may influence the migration process is important, including information about legacy architecture

22


model, its functionalities, the different type of dependencies to other applications, interaction points and message flow between legacy components, and quality of legacy code blocks for reuse and adaptation are important. In an experience in moving an online digital library search engine (CiteSeerX) to Amazon EC2, [S72] states that “an up-to-date and complete documentation can significantly reduce the length of learning and investigation time”. As an understanding of the legacy architecture model can be helpful in many ways: [S13], [S27], and [S60] suggest generating such models as a means of automatic transformation of legacy models to target cloud platforms. For example, the CloudMIG [S60], proposes OMG’s Knowledge Discovery Meta-Model (KDM) for extracting an abstract model of the application and transforming it to target cloud architecture. In another study by Rajaraajeswari et al., the activity Application Profiling is to identify the application usage data [S66] which helps to understand the size of workload to move to the cloud. This avoids the unexpected cost of cloud service usage when bills will be issued. According to [S66] the following data are required to be collected: (i) CPU and memory usage (ii), storage data such as input/output operations per second, (iii) network data such as throughput and connections per second, and (iv) the nodelevel data to estimate number and type of machines required when the application is migrated. 2.2.5 Target Cloud Platform/Service Selection (C5) As stated in Chauhan’s method [S9], a better alignment between the quality attributes of an application and cloud services will facilitate the legacy migration process. A similar conclusion, but from a cost perspective, has been made by Tran et. al. where a breakdown of activities is introduced for moving a .NET n-layer application to run on Windows Azure [S6]. They highlight the importance of the choice of cloud platform which influences efforts required for the rest of the migration process. If a chosen cloud platform is highly compatible with the legacy application technology, fewer code modifications in legacy will be required.

23


Furthermore, the following factors were identified for investigation when selecting cloud services/platforms: “the variety of service models offered by provider, price model, the form of SLA, additional services such as backup, monitoring, auto-scaling, security mechanisms, implementation technologies which are supported by provider such as programming languages, development platforms, allowing access to internal operational logs, the physical location of application data” [S2], “sustainability” [S4], “commitment durability with cloud provider”, “business objectives of migration to the cloud” [S9], “the degree of automation supported by the provider, storage encryption mechanisms, storage format and exchange”, “developer SDKs” [S10] and [S11], “required configuration effort, deployment speed, consistent development experience” [S23], and “traffic bandwidth at the client network” [S64]. Once a cloud platform is selected, a contract between the legacy application owner and the cloud service provider is signed. The application owner needs to specify the scope of expected service provisioning by the cloud provider prior to migrating the application components to the infrastructure of a cloud provider. The cloud service selection is finalised with producing an SLA that specifies both the boundary of usage as well as the provision of cloud services. The advantage of the elasticity offering by cloud services may raise a licensing issue. Assume an organisation has contracted for K number of application licenses and it pays a fixed annual fee. Once encapsulated into a virtual machine and run in the cloud, multiple instances of the application may be created by a server based on the workload fluctuation. As such, the restriction on K instances is unintendedly violated. In addressing this issue, for example, Amazon method recommends developers should extend the legacy application to new components such as VPN tunnel so that cloud services are indirectly offered to them [S71]. Alternatively, [S29] suggests enabling a license tracking mechanism through monitoring connections between the application and cloud services. Finally, the licensing issue can be resolved via a negotiation between the application owner and provider, in particular for migration types I, II, and V.

24


2.2.6 Re-Architecting Legacy Applications (C6) Re-architecting is a core concern in a legacy cloud enablement endeavour, involving the following sub-concerns. (i) Defining Cloud Architecture Model (C6.1). Two important aspects of rearchitecting are (i) identifying suitable legacy application components for the cloud migration and (ii) defining suitable deployment and distribution of these components on cloud servers. Conway and Curry in [S4] state “this [component selection] will require an understanding of the current state, so that it can be compared to the desired future state”. Additionally, Andrikopoulos et al. enumerate several factors to be taken into account for component selection, including data privacy, expected workload profile, acceptable network latency and performance variability, the availability zone of cloud providers, the affinity of components in the cloud, and the geographical location of cloud servers [S65]. Furthermore, Leymann et al. refer to the cloud architecture design as a “Move-to-Cloud Problem” and suggest the use of existing optimisation algorithms such as simulated annealing in order to find the most suitable distribution of legacy application components among different cloud servers [S12]. (ii) Enabling Application Elasticity (C6.2). Cloud environments can be viewed as an infinite pool of resources such as CPU, memory, storage space, and network bandwidth in a way that resources can be acquired and released by applications on the basis of demand (Fox et al., 2009, Brebner, 2012). Running an application in the cloud does not provide elasticity per se. Rather, the application should have mechanisms to effectively acquire and release resources under input workload to reduce resource consumption cost. Many legacy applications have not been designed with support for dynamic resource provisioning due to the assumption that the elasticity feature is supported by providing more powerful physical servers. Elasticity can be implemented by developing a new component either embedded in the application or separately hosted on a server node in order to continuously monitor the application/component resource usage variables and then perform appropriate action for resource acquisition and release based on scaling rules/conditions related to specific

25


workload thresholds, events, or metrics [S28] and [S74]. Addressing the resource elasticity is a concern in migration types I, II, and V. (iii) Enabling Multi-Tenancy (C6.3). In cloud environments, each service consumer is called a tenant (Rimal et al., 2009, Guo et al., 2007). Multi-tenancy is the ability of different tenants to use the same instance of a resource at the same time. For the cloud service provider, this maximises both resource utilisation and profit since it requires deploying only one application instance in the cloud. For the cloud consumer, it seems that he/she is the only user of the application. Tenants can customise application components, such as user interface appearance, business rules, and the sequence of workflow execution, and last but not least the application code. However, migration from a single-tenant to a multi-tenant may raise several issues, specifically in the case of applying the migration type II, as discussed in studies [S36], [S75], [S35], and [S37] and delineated in the following: — Security Isolation (C6.3.1). Enabling multi-tenancy, specifically in the case of applying migration type II, raises a security risk when different tenants run the same application instance and use the same database and shared resources. A malicious tenant can damage resources and pose a serious threat to all tenants. It is necessary to assure that each tenant can only access its own data and is protected from unauthorised access by other tenants running in the same cloud. As off-the-shelf database management systems might not support the multi-tenancy feature (Jacobs and Aulbach, 2007), securing the data layer of application should be properly addressed. Furthermore, the code blocks of the application that reflect organisational business processes (e.g., BPEL) might need to be secured and protected from unauthorised access by other tenants prior to deployment in the cloud. Therefore, assured confidentiality of code execution is required, for example, through encryption mechanisms, so that other tenants will not be able to access, read, or alter the code blocks within running application instances in the cloud. — Tenant-based application customisation (C6.3.2). Each tenant may have different functional and non-functional requirements. For example, one tenant may need an ability to customise an application user interface whilst others may need to change

26


the sequence of an application workflow and code customisation. Customisations applied by one tenant should not affect other tenants. To realise application customisability, a set of configuration points, in the form of an application template, should be defined in the code blocks of the application. One should not neglect the fact that due to one-to-many nature of cloud services, it may not be practical for providers to customise their services for all consumers. In addition, cloud providers might not be interested in developing services that enable customers to easily switch to other providers (Buyya et al., 2008, Weinhardt et al., 2009). Uncustomisable and proprietary APIs may hinder consumers from configuring cloud services to meet their specific application needs (Harmer et al., 2009). — Fault isolation (C6.3.3). If a fault occurs in the same instance of a running application instance, which is being used by multiple tenants in a shared manner, it should not be propagated to other tenants that are using that instance. The application should monitor its internal state to detect faults, prevent their propagation, and repair them in a timely manner. — Performance Isolation (C6.3.4). The fourth aspect of multi-tenancy is performance isolation, which is to guarantee the performance of one tenant from negatively being affected by unforeseen behaviours in the performance usage of other tenants. For example, the performance of a tenant that uses one core of a multicore processor may significantly be reduced when another tenant runs on an adjacent core process and performs a massive workload (Nathuji et al., 2010). If this condition is satisfied in all situations, then the application is performance-isolated. (iv) Addressing Interoperability and Incompatibility between Legacy Applications and Cloud Services (C6.4). Cloud environments are proliferated with various services that bring a wide range of possible building blocks to develop fully-fledged cloud applications. While advances in cloud computing are in progress, there is not a common standard for the development of cloud services (Toosi et al., 2014). Vendor lock-in is an inherent problem in the cloud and occurs when a cloud application is built via a

27


composition of cloud services developed by different providers. Each provider may use different underlying technologies and propriety APIs to develop its services (Fox et al., 2009). These issues face developers with heterogeneities across the application layer, which may imply a certain level of development and modification effort, specifically in the case of applying migration types I, II, III, IV, and V. If legacy is bound to specific cloud services, potential incompatibilities may occur between legacy components and cloud services. Incompatibilities between legacy and cloud originated from mismatches between codes, APIs, interface signatures, data types, and query calls. Existing studies report three forms of adaptation that might be required to resolve incompatibilities as follows: — Code refactoring (C6.4.1). A basic form of incompatibility resolution is through modifying legacy codes so that they can interact with cloud services [S11], [S40], [S6], [S9], and [S65]. This can be the modification of legacy interfaces in order to remove mismatches (e.g. interface signature, operation ordering, operation names, message format, interaction protocols, and data type) with cloud service interfaces. Also, behavioural adaptation is required if there is a mismatch in the granularity of message interaction between legacy components and cloud services. — Developing Integrators/Adaptors (C6.4.2). If code refactoring, as mentioned in the previous item, is costly, then developing integrators/adaptors (also called wrappers) can be used as an alternative solution to remove incompatibilities between legacy and cloud services. Adaptors provide an abstraction layer that keeps the legacy untouched and facilitates its interoperability and portability. In the migration method Architecture-Driven Modernisation (ADM), proposed by Zhang et al. [S13], developing wrapper layers (e.g. Web services) on legacy components is suggested to utilise cloud services. Furthermore, adaptors might be implemented to ease transforming legacy application components before deployment in the cloud or for applying changes during application runtime [S44]. Similarly, [S15] suggests static (or design-time) adaptation and run-time adaptation. The former defines adaptations required to be performed before an application is run in the cloud, whilst the latter

28


defines ways of applying adaptations at the runtime execution of an application in the cloud. — Data Adaptation (C6.4.3). Migrating the data layer of a legacy application to a cloud database solution can also raise some incompatibility issues. For instance, the cloud database solution SQL Azure is similar to traditional SQL Server. However, distributed transactions are not supported by SQL Azure in the same way as the SQL Server. This may imply a need for implementing some data type conversions, query transformations, database schema transformations, and developing runtime emulators for stored procedures, views or triggers [S25], [S11], and [S65]. With respect to the abovementioned incompatibilities, a cloud migration method is expected to provide proper activities and guidelines to identify and accordingly resolve possible incompatibilities beforehand; otherwise, the legacy application will not be able to utilise cloud services. (vi) Addressing Architectural Design Principles (C6.5). When re-architecting a legacy application to target cloud architecture, there is a range of design principles that should be taken into account during architectural design. These are: —Application decoupling (C6.5.1). To take the advantage of dynamic deployment, one architectural requirement is to decouple application components so that they can interact in a transparent manner [S62], [S55], and [S51]. Application decoupling enables independent elastic scaling of components (i.e., dynamically adding/removing instances of the same components), minimising the time required for code refactoring and testing in the case of switching to another cloud provider and handling a-synchronised communication and component failures. —Stateless programming (C6.5.2). To support dynamic deployment and scalability of an application in the cloud, it should be stateless and have minimal stored contextual data [S62], [S55], [S51]. Moreover, the coexistence of multiple running instances of the same components in the cloud requires new session management mechanisms in order to track tenant’s behaviour and ensure their security when the number of instances is increased or decreased based on the server workload.

29

Chapter 2. Literature Review —Handling the unpredictability of cloud environments (C6.5.3). Cloud services may not be accessible all the time due to reasons such service outage, network failure, transient problems in network, and service middleware failure. A common example is scaling latency, defined as the time required by a cloud server to provide a requested resource for a service consumer [S65]. To resolve these issues, developers need to empower the application with proper countermeasures to detect and handle such behaviours though in some cases unpredictability can be out of the control of an application owner and cloud provider. —Replicating and synchronising (C6.5.4). Replication is performed to increase business continuity and minimise downtime by running several application instances on a variable number of cloud infrastructures. Partitioning and replication may entail extending the application to support synchronisation of its components (local replicas and those hosted in the cloud). If a cloud provider supports this, then the application can leverage it [S72]. 2.2.7 Environment Configuration (C7) It is likely that a connection between application migrated to the cloud and a local network will be required. According to migration methods such as Tran’s [S6], Strauch’s [S11], Oracle [S25], and Amazon [S71], there is need for (i) reconfiguring an organisation’s network settings such as ports, devices, firewalls, and anti-virus, reachability policies, and connection strings to the database, (ii) set privileges to application tenants/users to assure the security of application is satisfied in the cloud environment, and (iii) creating installation scripts and setup different third-party libraries and tools that can be used for monitoring and reporting runtime application behaviour, although this needs less effort if a cloud provider has already done it in favour of service consumers. 2.2.8 Testing (C8) Once modifications are applied to a legacy application, testing is unavoidable to ensure

30


a migrated application satisfies cloud migration objectives/requirements. Like traditional software development, testing includes both functional and non-functional aspects. A test in the context of cloud migration can be extended to the following items. As mentioned in Section 2.2.5, for many reasons such as server workload or user preference, a running application may move from one cloud environment to another. With respect to this, a lesson learned stated by [S18] is to test application interoperability in heterogeneous cloud environments. Therefore, a certain level of integration and interoperability testing is required. Other tests to be considered are “Test Network Connectivity” (connection between cloud services and local network), “Test Connection Speed” as there is network latency to receive a response from the cloud server located in different geographical areas [S71], “Test provider performance variability” and “Test application latency” which is concerned with the network performance variability [S65]. 2.2.9 Tailoring (C9) Cloud migration introduces many challenges such as security, the location of data, required changes in applications, interoperability, legislation, and vendor lock-in (Armbrust et al., 2010). Such challenges make cloud adoption multi-faceted combined with several situational factors that should be properly addressed during the migration process. For example, according to (Louridas, 2010) there is a difference between the US and EU in addressing ultimate data protection in the cloud. That is, in the US, a cloud provider is responsible for complete data protection whilst in the EU, cloud consumers are finally responsible for ensuring the cloud provider satisfies data protection requirements. Any misunderstanding of this fact may affect application security and raise exposure to vulnerabilities. As such, activities attuned to securing legacy data should be incorporated into the migration process. In this spirit, researchers have paid great attention to engage tailoring for cloud adoption endeavours. Wang (Wang, 2015) describes the importance of method tailoring as follows “Cloud computing definitely has many attractive benefits to offer but there isn't a one size fits all formula for all customers' needs” (p. 4).

31


Additionally, Banerjee [S62] explores existing migration methods with challenges that act as a barrier for organisations to use cloud services and concludes: “There is no onesize-fits-all cloud, and it is up to each business to decide how much change is tolerable and to decide how far into the cloud to step” (p. 2). Furthermore, a call for designing configurable cloud migration methods is stated by Mahmood (Z.Mahmood, 2013): “There is an immense need to identify correct process model for the deployment of cloud-centric environments in order to meet changed business requirement of clients. One solution can never fit all problems; likewise, there is a need of customised cloud for individual businesses and dynamically changed requirements of clients”. While method adherence can be beneficial, constructing situation-specific methods or tailoring existing ones that meet the characteristics of migration scenarios at hand should not be overlooked.

2.3

A Review of Existing Cloud Migration Methods

The increasing adoption of cloud services as a viable IT initiative to empower legacy assets has led a number researchers and practitioners to ask what and how legacy to cloud migration is conducted. As a testimony to this, cloud migration methods are being published in dedicated journals, conference tracks, and workshops at an increasing rate. Such methods offer end-to-end lifecycles to conduct moving application to the cloud. This section reviews a dozen prominent methods suggested by both academies and industry. These methods were identified in the literature review, Section 2.2: Chauhan’s Method [S9], REMICS [S3], Tran’s Method [S6], Cloud-RMM [S68], Strauch’s Method [S11], Zhang’s Method [S13], Oracle’s Method [S25], ARTIST Method [S64], Amazon Method [S71], and Legacy-to-Cloud Migration Horseshoe [S27]. The following describes each method, distinguished characteristics, and suggested activities. 2.3.1 Chauhan’s Method This method is the result of experience gained in moving an Open Source System (OSS), called Hackystat, to two cloud platforms, Amazon Web Services and Google App Engine (Chauhan and Babar, 2012). It provides guidelines, lessons learned, and

32


key issues involved in the migration process. These include analysis of target cloud environments against specific application requirements, an evaluation of platforms based on quality attributes, the impact of a target cloud platform on each of the migration activities, and the potential influence of different services offered by cloud environments on migration activities and new architecture of an application to be migrated (Chauhan and Babar, 2012). As shown in Figure 2-3, the method starts with identifying high-level requirements and further decomposing them into fine granular functionalities. The activity Identification of potential cloud hosting lists candidate cloud platforms, according to project characteristics, mainly confidentiality and sensitivity requirements as well as long-term migration goals. Accordingly, incompatibilities of legacy application with cloud potential environments are analysed (activity Analysing applications’ compatibility). Next, a high-level architecture solution for the target application is defined and those components which are sensitive to different QoS are identified. The strengths and weaknesses of the proposed architecture solutions are then evaluated against QoS with an emphasis on scalability and accessibility. The method continues with analysing architecture requirements against the candidate providers in order to detect any conflicts between a proposed cloud architecture solution and a selected cloud provider. Finally, the designed solution is implemented and tested.

Figure ‎2-3 Chauhan’s‎method [S9]

33


2.3.2 REMICS REMICS (REuse and Migration of legacy applications to Interoperable Cloud Services) (Mohagheghi, 2011) method is based on agile practice and a model-driven engineering approach in order to move to interoperable service cloud platforms (Figure 2-4). As defined by Recover activity, the method starts with getting an understanding of legacy functionalities and an extraction of its architecture. The As-is and To-be application architecture models include different kinds of information from source codes and binaries are modelled by the UML (UML, 2004) class diagrams and deployment diagrams. This helps to identify a proper way to modernize and benefit from modeldriven techniques for the generation of a new application. Activity Migrate designs a new architecture for legacy by applying specific SOA/cloud computing patterns such as architecture decomposition, wrapping, and component replacement with cloud services. The migration process proceeds with two complementary activities: Model-Driven Interoperability and Validate, Control and Supervise where the legacy reengineers for a new platform in a forward model-driven process by applying specific transformations dedicated to service cloud platforms.

Figure ‎2-4 REMICS method- reproduced from [S3]

2.3.3 Tran’s Method This method is a result of an experience in moving a legacy to Windows Azure and Amazon EC2 (Tran et al., 2011). Based on a cost-oriented view, it defines a taxonomy

34


of migration activities and their cost-related factors. The main activities are categorized in five groups: (i) Training and learning curve aims to reach an understanding of the legacy application, its inter-connected components, and training the development team about third cloud party libraries, tools for data migration, and any required middlewares, (ii) Installation and configuration sets up tools in IaaS cloud, (iii) Code modifications refers to required modifications to database connections and queries to resolve incompatibility between the legacy and the chosen cloud platform, (iv) Migration configures the legacy and its database for hosting in the cloud, and finally (vi) Testing which evaluates whether local legacy components work properly with those hosted in the cloud environment. 2.3.4 Cloud-RMM Cloud-RMM (abbreviation for Cloud Reference Migration Model) is a conceptual method defined on the basis of a systematic literature review on cloud migration research (Jamshidi et al., 2013). It defines three phases and twenty migration activities (Figure 2-5). Migration planning phase refers to activities such as feasibility study, migration requirements analysis, decision making on cloud platform selection and legacy components to be migrated, and defining a suitable migration strategy. Migration execution phase comprises activities such as data extraction, legacy architecture recovery, legacy code modification and transformation. The third phase, Migration evaluation, is concerned with the validation and deployment of migrated application. Crosscutting concerns include governance, security analysis, training, effort estimation, organizational change, multi-tenancy, and elasticity analysis. Nevertheless, CloudRMM leaves operationalizing detailed information on the definitions of activities to developers.

35


Figure ‎2-5 Cloud-RMM migration framework [S68]

2.3.5 Strauch’s Method (S. Strauch, 2014) proposes a platform-independent method to reengineer the database layer of applications to a cloud service database solution (see Figure 2-4). It starts with formulating a migration strategy that considers properties such as live or non-live, complete or partial migration, and permanent or temporary migration (activity Select migration scenario). The activity Describe desired cloud data hosting solution defines functional and non-functional requirements regarding a target cloud data store. The method continues with the activity Select cloud data store or data service, where a cloud database solution is chosen with a specific focus on the mapping properties of cloud database solution as identified in the previous activity. The chosen cloud service may have

some

incompatibilities

with

the

legacy

database.

In

resolving

incompatibilities as suggested by Identify patterns to solve potential migration conflicts, the method offers a catalogue of data migration patterns. Since data layer migration to the cloud may influence other legacy layers, the method provides guidelines for refactoring with a special focus on network adaptation, the data access layer, and the business logic layer of the application. Finally, the activity Migrate data deals with the configuration of connection to the source and target data stores and credentials.

36


Figure ‎2-6 Strauch’s‎method [S11]

2.3.6 Zhang’s Method This is a seven-step method for monolithic applications being made as SaaS (Zhang et al., 2009). The method wraps valuable services of a legacy application in the form of Web-service deployable in the cloud. The method activities are as follows (Figure 2-7). First, the architecture of the legacy is identified on the basis of analyzing codes and test descriptions. Next, the legacy architecture is redesigned and refactored in the sense that developers identify services that can be provided in a SaaS architecture and model it in SoaML. Using model-driven transformation techniques, SoaML model is transformed into target code like WSDL and subsequently to target Web-service. A suitable cloud platform is chosen to support the execution of the generated Web-service. Finally, the cloud platform is configured to make a custom image of the application.

37


Figure ‎2-7 Zhang’s‎method [S13]

2.3.7 Oracle Method This method consists of seven phases (Laszewski and Nauduri, 2011) as shown in Figure 2-8. The assessment phase identifies migration drivers, tools/options, cloud platforms, effort estimation, training requirements, IT resource requirements, and the impact of cloud migration on organization functions. The Analysis and design phase determines the implementation details on a target database with a focus on security roles and privileges, transaction management, and SQL code, and resolving incompatibilities (e.g. schema layout, data type) between legacy database and target data store. The Migration phase moves data from the source data store to the cloud data store. It includes activities for modifying database schema and stored procedures, and data migration. The Testing phase constitutes activities such as data verification; the testing of migrated business logic in stored procedures, functions, and triggers, testing of application interaction with the new database platforms; and the testing of database maintenance scripts. Migrating from the legacy to cloud database can negatively affect performance due to insufficient resources acquisition or unpredictable workload. The method defines the optimization phase in order to monitor the migrated application to the cloud to identify and address any performance bottlenecks. Finally, Deployment phase includes activities such as hardware configuration, acquiring new hardware and software resources, initial data loading, testing backup, and recovery procedures.

38


Figure ‎2-8 Oracle method [S25]

2.3.8 ARTIST Method ARTIST (Menychtas et al., 2013) is based on a model-driven development approach and relies on model transformations and reusable platform independent models which can be automatically transformed to multiple cloud platforms (Figure 2-9). Models encapsulate application parameters for the migration to a specific platform using forward engineering techniques regarding requirements such as multi-tenancy and elasticity. The method includes four phases. The Migration feasibility assessment phase performs both technical and economic feasibility analysis as a prerequisite to the migration. The former provides a snapshot of the legacy code quality for reuse whilst the later investigates business values and risks of the migration process. On the basis of this phase, the rest of migration process is customized. The Application discovery and understanding phase, performed using model driven reverse engineering techniques, recaptures an overall logic of the legacy architecture and produces a platformindependent model (PIM) of the target application. In Modernization phase, using transformation patterns, PIMs models are gradually transformed to a cloud platform model that address requirements of application. This phase is based on gradual model refinements instead of directly generating target codes from PIMs allowing developers to control the degree of cloud enablement and optimization. In the Testing, Verification and Certification phase, the produced executable models are deployed in the target cloud platform and validated with a focus on behavioural equivalence and end-user functional and non-functional requirements. If the migration is successful, a

39


certification model is issued in order to increase customer confidence about the generated SaaS application.

Figure ‎2-9 ARTIST method [S64]

2.3.9 Amazon Method Amazon (Varia, 2010) proposes a method for migration to its cloud infrastructure in six phases: Cloud assessment, Proof of concept, Data migration, Application migration, Leverage the cloud, and Optimization (Figure 2-10). The Cloud assessment phase analyses security, compliance, financial, and technical aspects of cloud adoption. An important activity in this phase is to create a dependency tree showing legacy components and their upward and downstream dependencies to other applications. In addition, gaps between current legacy architecture and next-generation cloud architecture are identified. Another activity in this phase identifies suitable tools required to build or customize an application, estimates the effort required to migrate the application, and defines a cloud migration roadmap. The Proof of concept phase deploys and tests a prototype of an application for the cloud environment. This gives an estimation of whether migration is feasible. In Data migration phase, various data storages available in the AWS cloud are evaluated and appropriate ones are chosen to move legacy data to it. The Application migration phase analyses pros and cons of moving the whole legacy application stack (i.e. forklift migration) or some of its components (i.e. hybrid migration) without disrupting the current business processes of

40


an organization and leading developers to choose a suitable migration strategy. Once the application is deployed and tested in the cloud, the Leverage the Cloud phase investigates how to get additional benefits from the cloud such as more features and services, increasing automation, elasticity, and handling failure events. Finally, the Optimization phase focuses on understanding application usage patterns, terminating the under-utilized instances, implementing advanced monitoring, improving resource efficiency, and increasing cost saving.

Figure ‎2-10 Amazon process model [S71]

2.3.10 Legacy-to-Cloud Migration Horseshoe This method applies the notion of architecture-centric software evolution (Gustafsson et al., 2002) combined with a model-driven development approach (Ahmad and Babar, 2014). It includes four phases (Figure 2-11). The first phase, Architecture Migration Planning, performs a feasibility study of required effort and migration cost. The second phase, Architecture recovery aims to recover an architecture model of legacy source code, component interfaces, and to ensure the architectural descriptions are consistent with the source code. This high-level representation is essential to identify critical design rationales required to be preserved during modification/transformation of the legacy application to the cloud. Once the legacy architecture is recovered, the Architecture transformation phase modifies the legacy architecture towards a servicedriven cloud architecture by means of architecture transformation operators such as atomic and composite change operations. In fact, the method views the migration process as a set of recurring problems that can be formulated as process patterns. The last phase of the method, Architecture-based development, develops cloud-enabled source code from the designed cloud-service architecture, confirming that the cloud-

41


enabled source code is consistent with the target architecture model.

Figure ‎2-11 Legacy-to-Cloud Migration [S71]

2.4

Knowledge Gaps in Current Cloud Migration Literature

Table 2-4 and subsections below summarise and elaborate on the results of methods reviewed in Section 2.3 evaluated against the concerns described in Section 2.2. A three level scale point method (Kitchenham et al., 1997) was used in order to assign a value indicating the extent of support for a particular concern provided by a method. Levels were defined as: (i)

A Fully Supported: a method explicitly provides a clear description of relevant tasks and techniques to address a concern,

(ii)

A Partially Supported: no explanation is provided about a particular concern and details are lacking, and

(iii)

A Not Supported a method provides neither a partial definition nor explanation for a concern.

As elaborated below, the evaluation results revealed the conformance of the methods to the concerns and associated shortcomings and capabilities in each method in terms of treatment of the concerns.

42


Percentage of support

Legacy-to-Cloud Migration Horseshoe

Amazon Method

ARTIST Method

Oracle Method

Zhang’s Methodology

Strauch’s Method

Cloud-RMM

Tran’s Method

Concern

REMICS

Chauhan’s Method

Table ‎2-4 Evaluation results of cloud migration methods (Only fully supported were counted for calculations)

Analysing Organisational Context (C1)

30%

Understanding Cloud Migration Objectives and Requirements (C2)

60%

Proper Cloud Migration Planning (C3)

60%

Understanding Legacy Applications (C4)

50%

Target Cloud Platform/Service Selection (C5)

50%

ReArchitecting Legacy Applications (C6)

Defining Cloud Architecture Model (C6.1)

10%

Enabling Application Elasticity (C6.2)

10%

Enabling Multi-Tenancy (C6.3)

Addressing Interoperability and Incompatibility of Legacy Applications with Cloud Services (C6.4) Applying Architecture Design Principles (C6.5)

Security Isolation (C6.3.1)

0

Tenant-based customisation (C6.3.2)

0

Fault isolation (C6.3.3)

0

Performance Isolation (C6.3.4)

0

Code refactoring (C6.4.1)

20%

Developing Integrators/Adaptors (C6.4.2)

0

Data Adaptation (C6.4.3) Application Decoupling (C6.5.1)

30% 10%

Stateless Programming (C6.5.2) Handling the unpredictability of cloud (C6.5.3)

10% 0

43


Environment Configuration (C7)

40%

Testing (C8)

50%

Tailorability (C9) Percentage of support

10% 20%

21%

20%

0

15%

Legend A Fully Supported scale where a method explicitly provides a clear description of relevant tasks and techniques to address a concern A Partially Supported scale that refers to a particular concern but no explanation is provided about the concern and details are lacking A Not Supported scale means that a method provides neither a partial definition nor explanation for a concern.

44

10%

32%

35%

45%

20%


2.4.1 Limitations Regarding the Cloud Migration Concerns With

respect

to

the

concerns

Enabling

Multi-tenancy

(C6.3),

Developing

Integrators/Adaptors (C6.4.2), and Handling the Unpredictability of Cloud (C6.5.3), the last column of Table 2-4 illustrates none have been supported by any of the methods despite the emphasis in the cloud migration literature (Sections 2.2.5). Cloud-RMM [S68] includes Enabling Multi-tenancy (C6.3) in its process model but no definition is given. Furthermore, the majority of the methods have neglected to incorporate relevant tasks to the concerns Defining Cloud Architecture Model (C6.1), Enabling Application Elasticity (C6.2), and Applying Architecture Design Principles (in particular Application Decoupling (C6.5.1) and Stateless Programming (C6.5.2)) in their suggested models. More specifically, Amazon method supports Enabling Application Elasticity (C6.2) and Stateless Programming (C6.5.2), Zhang’s method [S13] supports Application Decoupling (C6.5.1), and Chauhan’s method supports Defining Cloud Architecture Model (C6.1); hence only 10% of the methodologies support these concerns. Another gap exists in relation to incompatibility issues between existing applications and cloud services, as specified by the concerns Code Refactoring (C6.4.1) and Data Adaptation (C6.4.3), which have been weakly supported by existing methods. In other words, only Tran’s [S6], Strauch’s [S11], and Oracle [S25] methods define activities for adapting the data layer of a legacy, which might be incompatible with a chosen cloud database solution. Other methods provide no explanations for addressing these concerns. And finally, with respect to the last row of Table 2-4, there is no method that addresses all twenty concerns. Any of the methods, except for Amazon [S71], explicitly support more than nine of the total twenty (i.e. 45%) migration concerns, while Cloud-RMM [S68] and Zhang’s [S13] methods weakly support most of the concerns, that is, 0% and 11%, respectively.

45


2.4.2 Lack of Tailorability Support With respect to Tailorability (C9), the majority of existing methods have been designed based on an assumption of one-size-fits-all and support for a method tailoring is intangible and difficult to find. The methods REMICS [S3] and ARTIST [S64], jointly, refer to tailoring as method extensibility. REMICS method is stored as a set of building blocks that can be further selected and assembled to create a method regarding characteristics of a project at hand. The method’s activities have been presented in a textual format without direct support for method customisation. ARTIST provides a tool that allows customisation and instantiation of the method based on cloud migration feasibility analysis results. Nevertheless, the method is associated with common migration activities and it does not differentiate between activities required to perform different service delivery models. The current research argues that combining existing methods into a comprehensive migration method cannot be a proper solution since locally-based activities in each method are sometimes irreconcilable and inconsistent. 2.4.3 Lack of Integrity Other than the methods reviewed in Section 2.3, there are abundant studies in the literature about exploiting cloud services and the process of the transitioning to the cloud. It is hard to find any two cloud migration solutions published in the literature that use the same definition for migration activities. Furthermore, many existing solutions narrowed down to platform specific details and often are not homogeneous. As an illustrative example of the variety of definitions, the concern Cloud Service Selection (C5) in the reviewed methods: Legacy-to-Cloud Migration Horseshoe [S27] is defined as “once the requirements are elicited and prioritised, an important activity is to consider the cloud (PaaS) provider”. Similarly, Strauch’s method [S11] states that “the concrete target data store or data service for the migration is selected by mapping the properties of the Cloud Data Hosting Solution to the set of available data stores and data services that have been categorised according to the same non-functional and functional properties”. Finally, Chauhan’s method [S9] denotes this concern as a “trade-off analysis document specifying pros and cons of [cloud] environments and their suitability with applications from business and technology perspectives”. Hence,

46


Legacy-to-Cloud Migration Horseshoe focuses on the choice of a suitable PaaS, whereas Strauch’s method focuses on the choice of cloud database solutions and Chauhan’s definition emphasises the significance of business and technical suitability of cloud platforms. Such variation is not surprising if one considers different IT backgrounds and experience of designers of these methods. Nonetheless, it would have been helpful to the cloud computing community if all interpretations from various sources could be encompassed in a hybrid definition while still maintaining generality, coherency, and consistency. Prior research in IS and software engineering have pinpointed that although a variety of methods for any given domain is profitable at the beginning of a research field, a generic reference model of what the various domain-specific methods looks like is eventually more efficacious, since it facilitates (i) communication across the community, (ii) understanding of the domain concepts instead of looking for them in dispersed literature, (iii) portability across modelling tools, and (iv) tailoring and specialisation for a given situation at hand (Rossi et al., 2004b, Beydoun et al., 2009, Harmsen et al., 1994). In line with this argument, developing reference models to demystify the multifaceted, yet ambiguous notion of cloud computing is a research strand in the field (Mell and Grance, 2009, Armbrust et al., 2010). In particular, scholars (Hamdaqa and Tahvildari, 2012, Zimmermann et al., 2012) have articulated a clear need to engage more thoroughly with establishing a unified view of the cloud migration process. As a testimony to this, Hamdaqa and Tahvildari who proposed developing unified models of cloud computing concepts, characteristics, models, and architectures research landscape proposal, pointing out that (Hamdaqa and Tahvildari, 2012): “Unsurprisingly, the new model [Cloud Computing] created a state of confusion; new concepts are mixed with old ones, and some old technologies are being reinvented. Today, many research areas and projects under the cloud umbrella need to be sorted and classified […] It is important to learn from what already exists and to be able to distinguish between what is new and what can be reused”(p. 1) In an endeavour towards the conceptualisation of cloud architecture model, Hamdaqa et al. mention there is a need to detach the cloud application development process from specific cloud platforms (Hamdaqa et al., 2011). Similarly, Nguyen et al. state that a

47


barrier to entry for the cloud computing can be facilitated through a generic model providing common aspects of the cloud on multiple abstraction layers (Nguyen et al., 2011). Therefore, this research raises another issue that while the existing cloud migration literature has merits, a pressing question is how can one gain an overarching and technical-independent understanding of the cloud migration process that can be tailored to particular needs? So far, the answer to this question remains unknown and the current research is a step towards resolving it. The fact that each year a considerable number of research papers are published in the cloud computing field, where each reports different solutions, experience reports, and recommendations to move legacy assets to cloud environments, itself suggests that the field has reached a maturity level where the development of one such generic reference model is mandatory. For example, a simple title-based search in the IEEE Explorer for the terms Cloud Migration returns over 1000 results. Such a lack of uniformity may account for difficulties confronted by IS and software engineering practitioners and scholars in understanding and managing the cloud migration process which is currently dispersed and fragmented in the literature. It would be helpful if commonalities in the existing migration methods could be factored out into one unified process model at a convenient abstraction level. Adequately crafted, it would help IS researchers and practitioners get the complete vision of a cloud migration process which is transparent and independent of any specific cloud platform. However, there is a dearth of studies that reconcile multiple and disparate migration approaches into an integrated model that demonstrates the core phases and activities of the migration process. None of the cited studies in Section 2.2 and reviewed methods in Section 2.3 have explored this inquiry. 2.4.4 Overview of Gaps This review of existing cloud migration methods has shown a lack of rigour in the methodological aspect of cloud adoption and thus a knowledge gap was identified for improving the status quo. In connection with the research motivations discussed in Section 1.2 and the observations from the methods reviewed in Section 2.3, the current state of affairs in the cloud migration literature shows the following gap:

48


The methodological aspect of cloud migration have not been well understood and suffers from (i) inadequate support for all concerns C1 to C9 addressing them are critical during the cloud migration process, (ii) an exorbitant focus towards technicalcentric implementations and domain specific details, and (iii) a lack of support for method tailoring. As a consequence, a solid framework is lacking to support the cloud migration process and enable creating and maintain bespoke methods that suit given migration scenarios at hand. The goal of this research is to fill these gaps (see also Section 1.2). Notwithstanding the abovementioned deficiencies, the current state of the cloud migration literature has merit and research targeting to improve this area as an ongoing track. The next step is to define a research agenda in order to address the stated gap, which is the main discussion in the next section.

49


2.5

A Solution Proposal

This section goes to the solution space to address the research gaps stated in Section 2.4. The section is divided into three parts. Section 2.5.1 reviews an excerpt of theories and approaches that have been used to understand the nature of cloud migration and chooses one that can be a viable underlying solution for addressing the research gaps presented in Section 2.4.4. This research introduces the notion of model-driven software engineering and, particularly, focuses on the metamodeling approach, which is described in 2.5.2. Next, Section 2.5.3 presents the proposed framework. 2.5.1 A Review on Theories Adopted to Understand Cloud Computing Adoption The adoption of cloud computing technology can be informed by different theories. This section presents a review of such theories used in the literature to understand the cloud adoption. Agency theory is about understanding coordination and motivation issues around a relationship between a principal (the client) and an agent (the outsourcer) (Eisenhardt, 1989). It is believed that opportunism is an inherent feature of such a relationship. That is, the principal or agent seeks to deviate from the contract for its own benefit by cheating, lying, or shirking. Opportunistic behaviours are confined by moral, ethical, and social norms. (Pallas, 2014) uses agency theory to understand and analyse conflicts of interests occurring between cloud service providers and service consumers. The study categorizes and assesses countermeasures to these conflicts and identifies possible technical and non-technical means to extend the applicability of cloud computing. Transaction cost theory highlights the role of transaction costs and uncertainties, such as technological uncertainties, that surround a market (Williamson, 1985). Transaction costs are associated with the time and effort required to search, negotiate, and maintain a relationship with customers (Williamson, 1985). The premise of the study (Yigitbasioglu, 2014) is that organisations have concerns with cloud adoption because liabilities may not be clearly specified like traditional outsourcing and the nature of

50


cloud adoption involves different roles and foreign legislation. Using the transaction cost theory, the author explores the impact of uncertainty around the legislation of cloud migration on perceived reliability and security. Results of the study show behavioural uncertainty such as the opportunism of a cloud service provider is positively related to security risk. Furthermore, the study develops some constructs to represent confidentiality, integrity, and availability of information. The theory of innovation assimilation mentions the adoption of a new technology, herein information system innovation in the context of this research, is not binary; rather it is multifaceted. Meyer et al. (Meyer and Goes, 1988) define assimilation as “an organizational process set in motion when individual organization members first hear of an innovation’s development” (p. 897). Through this theory, Conboy et al. (Conboy and Morgan, 2012) examine cloud computing adoption from three aspects (i) acceptance, the extent to which organisation’s staff have commitment to adopt cloud services, (ii) routinization, the extent to which the cloud is used in daily activities of an organisation, and (iii) infusion, the extent to which more features provided by cloud services are utilized than originally planned. This theory allows for discuss of the benefits (e.g. user-friendly and cut down on administrative tasks) and challenges (e.g. training cost) associated with an organization’s use of the cloud computing. According to (Clark, 1986), migration theory refers to the physical movement of people, i.e. migrants, from one geographic location to another for a certain period of time. Migration can be a short or long term, short or long distance, and voluntary or obligatory. Nevertheless, a migration should have some permanence, clear source and target locations (Lee, 1966). Using this theoretical perspective and drawn from a sample of students using Google Apps, Bhattacherjee et al. in (Bhattacherjee and Park, 2014) explain why end users move from client-hosted to cloud computing platforms. The study presents and empirically validates a model showing pull factors (e.g. dissatisfaction with client IT and relative usefulness) and push factors (e.g. learning cost, setup cost, and security concerns). However, the authors state that despite the presence of these factors, users may not universally migrate to the cloud due to obstacles such as switching costs or personal judgment.

51


It is important to realize that as the objective of this research (Section 1.2) and the identified research gaps (Section 2.4.4) are defined from a methodological point of view, none of the abovementioned theories provides a foundation for the improvement of the status quo. Accordingly, theories or approaches informing methodological aspects of cloud migration should be sought. This research suggests the notion of Model-Driven Software Engineering (MDSE) as a theoretical lens, through which a solution framework is developed. This is discussed in the next section.

2.5.2 Model-Driven Software Engineering (MDSE) The following subsections provide background to MDSE, which is used to the development of the proposed solution to address the gaps identified in the literature. Section 2.5.2.1 provides a background on the MDSE, followed by introducing notions of the metamodel in Section 2.5.2.2 and the method engineering approach in Section 2.5.2.3. Next, Section 2.5.2.4 introduces a metamodeling framework upon which the current study is based on. A variety of model transformation techniques and their relevance to this research are discussed in Section 2.5.2.5. Section 2.5.2.6 reviews a set of common design principles (also called quality factors) relevant to design and evaluation of metamodels. Finally, Section 2.5.2.7 presents a literature review of applications of metamodels in the cloud computing field. 2.5.2.1 Background

From the early days of software development, modeling and modeling language creation have been a common activity for raising the level of abstraction, reducing the complexity of software development, and the separation of concerns (Stahl et al., 2006). Programming languages such as Assembly, FORTRAN, COBOL, C++, JAVA, and operating systems and many other modelling technologies, e.g. UML, which aim to shield developers from the complexity of software design, programming CPU, memory, network devices, and underlying computing environments are good examples of such efforts. In this spirit, MDSE has emerged as a continuation of this trend which views the development process of information software system as a world of models (Schmidt, 2006). Models are primary artefacts of the software development process, generated and

52


transformed to executable software application. With MDSE, the complexity of a development process is alleviated by increasing the abstraction level between the desired software product and its concrete implementation. Models are used to describe target software at several abstraction levels, from different perspectives, and through transformation techniques become executable software (Atkinson and Kuhne, 2003). In the model-driven approach, the focus of developers shifts from programming and lowlevel technical details towards designing high-level models that are sufficiently abstract and reusable to be transformed to any target model, for example, code models, according to developers’ needs and required concretion. Such harness reduces the complexity of software development and contributes to a better understanding of the target software, more effective communication between developers, increased productivity of software development, and last but not least portability and maintainability of the target software. In MDSE literature, several definitions can be found for the model. From a simplistic view, Kühne (Kühne, 2006) defines a model as “an abstraction of a (real or languagebased) system allowing predictions or inferences to be made”. Gonzalez-Perez (Gonzalez-Perez and Henderson-Sellers, 2008) defines it as “a statement about a given subject under study, expressed in a given language” (p.32), language referring to the way of expressing a model. A modelling language defines all elements (or concepts) required to represent a domain under study. In this regard, models are not monolithic, they include individual entities that can be combined to imitate the domain. Suitably designed, a modelling language enables developers a better description for sharing common knowledge of a complex domain through abstract models. A good analogy is the developing and maintaining of class libraries in object-oriented programming (Gonzalez-Perez and Henderson-Sellers, 2008). With respect to this idea, a major stream in the MDSE area is to design modeling languages for a particular domain, called domain-specific modeling language (DSML). A good example of MDSE effort is UML that has received support from OMG standard in 1997 (UML, 2004). UML provides many notations to specify different aspects of a software application from early to late stages of development process, from a behavioural to a structural, and from a certain viewpoint to a level of abstraction.

53


DSMLs, discussed in the next section, have also been applied to model and maintain the knowledge of a domain of interest. 2.5.2.2 Role of Metamodels

A metamodel is a core concept in MDSE. Simply defined, a metamodel is a model of a model or a model of a collection of models (Atkinson and Kuhne, 2003). A metamodel for a particular domain is a DSML, which describes the domain in an effective manner along with guidelines to specialise it into a given particular context at hand

and

includes all related concepts, their attributes, semantics, relations, and operations in the domain (Gonzalez-Perez and Henderson-Sellers, 2008). Suitably crafted, a metamodel can provide a language infrastructure to freely model a domain and reduce its ambiguity. OMG (OMG, 2002) defines a metamodel as a high-level model that defines a language to express a model. Metamodels, models, and real-world domain have an instance relationship in the sense that a real-world element is an instance of a model and a model, by itself, is an instance of a metamodel. This relationship is depicted in Figure 2-12. An illustrative example, is an analogy between a programming language grammar and a computer program where a developer uses the programming language to define the computer program. The computer program can be executed only if it conforms to the programming language. The execution of the program is an instantiation of the computer program that is configured with different input parameters determined by a user.

Figure ‎2-12 Relationships between domain, model, and metamodel (Stahl et al., 2006)

A software development method is a complex structure constituting many concepts that are interrelated in a complicated way (Gonzalez-Perez and Henderson-Sellers, 2008). ISD methods are used to express and communicate knowledge and rationale about software development processes (Agerfalk and Fitzgerald, 2005). At the first instance, one may think that a method can be documented in the form of textual papers in a natural language. Although this can be acceptable for maintaining a method, it can be

54


problematic too. For example, assume a method includes elements such as activities, their definitions, relationships and sequences, roles involved, and the list of outcomes as a result of performing activities. Given a natural language to describe the method, if an element in this textual format is changed, then the entire document should be manually updated and controlled for consistency and accuracy. As such, maintaining a good-sized method can be cumbersome. Providing a solution to this problem calls for finding a more precise way to model methods as mentioned in the following. Gonzalez-Perez and Henderson-Sellers (Gonzalez-Perez and Henderson-Sellers, 2008) suggest an alternative way to describe and maintain a method is to use a modeling language. Their justification is that a method is a model that describes what and how to conduct things. Compared to a natural language, a modeling language is a way of adding rigor to describing a method: “such modeling language must be generic enough so that any conceivable method can be expressed but, at the same time, concrete enough so that major methodological concepts can be treated with specific semantic” (p. 15). As a method is a model, a modeling language that can describe a method is called metamodel. Accordingly, a metamodel, in the context of ISD methods, is a model of a method or, indeed, of a family of related methods (Gonzalez-Perez et al., 2005). Hence, the cloud migration methods reviewed in Section 2.3 are various models, each offering a solution for moving to cloud platforms. 2.5.2.3 A Review on Method Engineering Approach

Metamodels are integral components of the method engineering approach, defined by (Brinkkemper, 1996) as a “discipline to design, construct, and adapt methods, techniques, and tools for the development of information systems” (p.25). They have been introduced as a way to design flexible and situated ISD methods by either constructing a customized method or tailoring existing ones (Brinkkemper, 1996). The raw materials a method engineer uses for method construction or configuration are called method fragments. They are atomic and reusable pieces to modularise methods (Cossentino et al., 2006) and can be either obtained from existing methods or created from scratch as a result of experience gained from past system development effort (Ralyté et al., 2003). Method fragments are stored in a specialised database called

55


Repository (or Method base) (Ralyté, 2004), into which it is possible to incorporate, e.g. the latest best practices. While method engineering suggests storing methods as a collection of reusable method fragments for further situational method construction, metamodels facilitate acquiring, representing, and using such fragments (Henderson-Sellers and Ralyté, 2010, Brinkkemper et al., 1999). With respect to this, Ralyté et al., (Ralyté et al., 2003) refers to metamodels as a “core technique in method engineering” (p.107). The literature shows different approaches to situational method engineering to address characteristics of a project such as organisational, human, application domain, and development strategy. They are briefly described in the following. Using repository-stored method fragments for method construction is referred to as an Assembly-based approach where pre-existing method fragments are selected and assembled into a method based on the situational context (Brinkkemper, 1996). In (Ralyté and Rolland, 2001) a technique is suggested to guide the retrieval and assembly of method fragments depending on the type of situation. This approach facilitates reuse of method fragments, especially when they are sourced from existing methods for tailoring. This approach is similar to the Contingency-based approach (van Slooten and Hodes, 1996), which introduces the notion of a route map, a technique used later in (Aydin and Harmsen, 2002). Following the idea of assembly-based method engineering, Jamshidi et al. (Jamshidi et al., 2015) propose an approach wherein a methodology is constructed through combining architectural migration patterns; though, there is no further elaboration to accommodate configuration and tailoring. The weakness of the assembly-based approach is that creating meaningful methods needs sufficient knowledge and is error-prone in comparison with a Configuration-based approach, described next. This approach as introduced based on extensive action research (Karlsson and Ågerfalk, 2004) and (Karlsson, 2013) where it was found that method engineers often use existing in-house methods or already possible configurations instead of creating a method from scratch. Hence, these authors suggest method for method configuration, based on the notion of method components and impacts of project characteristics on the method rationale, presented by method component descriptors. A characteristic is represented

56


via a number of questions and configuration packages correspond to the answers. Such approach, as Rossi et al. (Rossi et al., 2004a) mention leads to “learning by doing” (p. 707). In the Extension-based approach (Deneckère and Souveyet, 1998), some extension points are identified from a base method and then extended through a set of mechanisms such as process patterns (Ambler, 1998). This can be challenging because any extension to a method has to be compatible with the method itself (Ramsin and Paige, 2008). Hence, method engineers do not have flexibility in applying modifications and refinements to the method. Extensions that are made to agile methods (Fitzgerald et al., 2006) are good examples in the sense that extensions should not impede agility and activities should be easily performed. In the literature, REMICS (Mohagheghi, 2011) method can be viewed as an instance of the Extension-based approach where an agilebased method, Scrum, is enriched with a few cloud-specific method fragments to support cloud adoption. Another option is a Paradigm-based approach (Ralyté et al., 2003) in which a new method is configured by instantiation from an existing method metamodel related to a particular domain or abstracting an existing method. For example, the OPEN framework (Firesmith and Henderson-Sellers, 2002) uses a metamodel, from which all fragments are created and stored. In the case of introducing a new technology and existing method fragments are insufficient, new fragments need to conform to the OPEN metamodel with appropriate quality control, and stored in the method base. In the Goal-oriented approach, the aim to balance and harmonize the system developers’ goals in a particular project with the goals defining a method, or parts thereof, which they chose to adopt (Karlsson and Ågerfalk, 2009). This implies that there is a need to preserve goals and values of the method otherwise the core idea of the method might be missed. An Ad-hoc approach (Ralyté, 2004) creates a new method from scratch regardless of existing methods. This is suitable when a problem domain is not mature and existing methods do not support it adequately. It can be also applied to augment the assembly, extension, and paradigm-based approaches. In the current research, applying metamodeling is viewed as a potential solution to the

57


gap stated in Section 2.4 in that it captures core development constructs including phase, tasks, and work-products and offers a comprehensive generic migration process that fills the deficiencies of existing cloud migration methods (Section 2.4). In addition, a metamodel provides a general understanding of the cloud migration process and at the same time does not narrow down into technical implementation details demanded in a specific cloud migration scenario. In fact, details are hidden behind the general constructs and their definitions are left to each individual user to be extended in order to suit a given migration scenario at hand. The metamodel facilitates standardisation, sharing, and exchange of knowledge about cloud migration processes across the community. Furthermore, among the reviewed method engineering approaches, this research views the paradigm-based method as suitable for creating and configuring cloud migration methods. This will be discussed in Section 4.3. 2.5.2.4 OMG Metamodeling Framework

The metamodel for this research is based on OMG modelling infrastructure (OMG, 2003). OMG promotes the idea of model-driven development where models play centroid role in the software development process, and are customisable for different contexts, interpretable, and transformable by computers. Figure 2-13 shows four-layers of language infrastructure that scaffolds the notion of model-driven software development as used to develop core technologies such as UML and MOF. These abstraction layers, which have an instance-of relationship with each other, are defined as follows (Atkinson and Kuhne, 2003): — The M3-layer is meta-metamodel describing basic modelling constructs. — The M2-layer defines constructs of a metamodel (an instance of M3- layer) to define a language for specifying models. As M2-layer is a model of a model, it is referred to as a metamodel. — The M1-layer (an instance of M2- layer) holds a language to describe a domain. It holds a model of the M0-level user data. — The M0-layer is the lowest layer (an instance of M1- layer) describing actual user data in a domain model. According to the abovementioned modelling infrastructure, each layer is considered as a

58


model expressed in the language defined by the layer above it. The derivation of a model from its upper layer is called conformance. In other words, a model is said to conform to a metamodel if every construct used in the model definition and constraints and rules for use are specified by the metamodel (Cicchetti et al., 2011, Paige et al., 2007a, Rose et al., 2010). The conformance is defined by a set of constraints encoded into the metamodel. For example, by a realisation of a construct in M2-layer, a new instance is achieved at the M1-layer. During a conformation process, all constructs in a M2- layer can be used to represent a model at the M1-layer. In OMG, a domain construct defined in a metamodel (M2-layer) is represented as a Class. The instantiation of the Class is represented as an Object (M1-layer). The Object contains actual data for a domain Class. Such a process is also definable for Class and Object at the M1-layer and M0-layer as well. To define a metamodel, a metamodeling language is required that, in turn, it is described by a meta-meta model.

Figure ‎2-13 OMG four abstraction layer hierarchy (Henderson-Sellers and Bulthuis, 1998)

Metamodels are used to add rigor to ill-structured ISD methods or software process models as described in textbooks, papers, and documents (Gonzalez-Perez and Henderson-Sellers, 2008). An ISD method is positioned at the M1-layer describing a collection of phases, activities, and guidelines to develop a software application. When enacted by software developers, it is referred to as an endeavour, which is situated at M0-layer. The endeavour is a real-world enactment of the method. Several scholars acknowledge the application of metamodels as a way of describing a model of a method or a family of related methods in a particular domain (Gonzalez-Perez and HendersonSellers, 2007, Brinkkemper et al., 1999, Susi et al., 2005, Rolland et al., 1995). Hence, methods placed at M1-layer can be modelled by a metamodel.

59


Metamodeling provides a foundation to build DSLs (Atkinson and Kühne, 2002). According to Gonzalez-Perez (Gonzalez-Perez and Henderson-Sellers, 2008) the term metamodeling refers to “the act and science of creating meta-models, which are a qualified variant of models” (p. 32). A metamodelling process, i.e. developing a metamodel for a given domain, generally intends to build a collection of classes, relations, and constraints to express concepts in the domain, though they may not be expressed exactly in the same way (Sowa, 1984). Metamodeling is a complex process and demands expertise and knowledge of a problem domain, which might be very fragmented, diverse, and ill-structured. It is expected that a produced metamodel be understandable and explainable to its users and adequately represent the domain (Sánchez-Cuadrado et al., 2012, Cicchetti et al., 2011). To achieve this, several techniques have been suggested in the MDSE literature, each varying in details of steps for metamodel creation and domain. Table 2-5 shows an excerpt of these techniques. Although these techniques differ in suggested steps, they follow an iterative restructuring and refinement process towards a final version. They start with collecting a list of sources relevant to a domain. Following with the identification of domain concepts from these sources, the reconciliation and harmonisation of different concepts, and the definition of relations between the concepts, an initial metamodel is produced. The primary model is examined by different techniques and gradually refined to reach expected quality. Table ‎2-5 Existing techniques for metamodeling

Study (Lopes, 1997)

Domain Real estate management

(Beydoun 2009)

et

al.,

Agent-oriented software development

(Othman 2014)

et

al.,

Disaster management

Suggested technique (i) Review the literature on the subject matter, (ii) Gather studies, and (iii) Extract and code information from the studies, and build an overall framework with the extracted information. (i) Identify a set of general concepts relevant to any multi-agent applications, (ii) Shortlist the candidate definitions, (iii) Reconcile differences between definitions, (iv) Classify concepts into design and run time aspects of software application, (v) Identify relationships within both design-time and runtime, and (vi) Validate the obtained metamodel against existing metmaodel in the literature and improve it accordingly. (i) Identify knowledge sources, (ii) Identify a set of models for the validation of the metamodel, (iii) Extract concepts, (iv) Short-list candidate concept definitions, (v) Reconcile candidate definitions, (vi) Design phases and placing the concepts in the phases, (vii) Identify

60


(Keller and König, 2014)

Risk management in Cloud Computing

(Gholami 2010)

et

al.,

Software development methods

(Cicchetti 2011)

et

al.,

In general

(Sánchez-Cuadrado et al., 2012)

In general

(Selic, 2007)

In general

relationships between concepts and resultant DMM, (viii) Compare against other models, (ix) Use a frequency-based selection technique, and (x) Use a tracing technique in real disaster scenarios to evaluate the metamodel. (i) Review the cloud computing literature, (ii) Identify the connections between concepts such as actors in cloud networks, (iii) Identify the causalities between the concepts, and (iv) Identify association between concepts. (i) Unify methods, (ii) Determine phase patterns, (iii) Decompose the methods, (iv) Determine stage patterns, (v) Concretise task patterns, and (vi) Store the patterns in a library. (i) Identify domain concepts and relations, (ii) Implement and refine the metamodel, (iii) Write a test model, (iv) Execute, and (v) Evaluate. (i) Define of model fragments, (ii) Induct, (iii) Refactor, (iv) Explore decisions, and (v) Compile for Specific Platforms. (i) Identify a  set  of  fundamental  language constructs, (ii) Define a  set  of valid  relationships, (iii) Define a  set  of  constraints, (v) Define concrete syntax or notation, and (vi) Define the  semantics  of meaning  of  the language.

2.5.2.5 Model Transformation

In MDSE, models are changed and evolved through transformation. Model transformation is a profound aspect of MDSE (Mens and Van Gorp, 2006). OMG started a standardisation process by publishing a request for proposals on Query/Views/Transformations (QVT) (MOF, 2002). This process aimed at defining the OMG standard for the model transformation definition and synchronisation between models. Kleppe et al. (Kleppe et al., 2003) define model transformation as “an automatic generation of a target model from a source model, according to a transformation definition. A transformation definition is a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language. A transformation rule is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language” (p. 32). Considering the hierarchical model of OMG (Figure 2-13), different views on model transformation in studies (Mens and Van Gorp, 2006, France and Bieman, 2001) are reviewed in terms of their relevance to the context of the current research.

61


The first view, is Endogenous versus Exogenous transformation. Endogenous occurs between models that have been expressed in the same language, for example code refactoring where the internal structure of a software application is modified to improve certain qualify factors (Fowler, 1999, Mens, 2006). Another example is a software release resulting of a corrective, adaptive, or perfective maintenance (France and Bieman, 2001). On the other hand, exogenous transformation between models is expressed in different languages, e.g., a code generation, where software source code is translated into bytecodes. The second viewpoint is Horisontal and Vertical transformation. In horizontal transformation, the source and target models are presented at the same level of abstraction (Koch, 2007, Mens, 2006) and it is performed in order to generate a new view of a domain. Vertical transformation is performed between source and target models residing at different abstraction levels. For example, horizontal transformation is a refactoring activity and vertical transformation is the gradual refinement of a model by adding detailed information to it. One can view that the horisontal and vertical model transformations as a move towards model evolution and concretisation, respectively. There are several implementation techniques are available in the MDSE literature (Budinsky et al., 1996, Meijler et al., 1997, Sendall, 2003); however, discussion of these them is out of the scope of this research. Taking the MOF modelling framework into account, a horisontal or endogenous transformation is definable at all levels. Model transformation at the M3-level is meant as a change in the modelling paradigm (Terrasse, 2001). Horisontal transformation at M2-level is the adding extra views to a metamodel to describe new aspects of a domain. Horisontal transformation at M1-level occurs when a model evolves itself. For example, application source codes might be extended with new functionalities. Any modifications to the codes are propagated to every model related to the code. The horisontal transformation has been applied to the proposed framework in this research, based on feedback from experts’ suggestions, expert peer review, and realworld case studies. Each evaluation provided new information which was sequentially evolve the framework to a new refined version. These transformations were at the M2level where the framework was a source model and it was evolved to a new target

62


framework. The results of horizsontal transformation are presented in Chapter 5, Chapter 6, and Chapter 7. Vertical transformation was used in the current research when a real-world migration process was derived from the framework, i.e. a model transformation from M2-level to M1-level. During a derivation process, each construct in the M1-level corresponded to a construct at the framework level. In this transformation, the framework is the source model and an instantiated model from the framework, a target model. This transformation is presented in Chapter 6. The difference between the terms instantiation and conformance is worth clarifying as sometimes these terms are used interchangeably in MSDE literature. According to Henderson-Sellers (Henderson-Sellers, 2011), “a model is said to conform to its metamodel when each element in the model maps to a corresponding and definitional element in the metamodel” (p. 16). For example, UML includes a construct that is called Class. During a modelling activity, this construct can be used as Bank class, Customer class, or an ATM class, which are objects. Herein, it can be said that each of these can be mapped to the construct Class in UML and hence they conform UML. Nevertheless, the instantiation is meant as a specific relationship between a class and an object. Paige mentions, in relation to model conformance, a model is checked whether it satisfies constraints defined in the metamodel and is indeed a valid instantiation of the metamodel (Paige et al., 2007b). Accordingly, the notion of conformance is more general and refers to many-to-many relationships whilst the term instantiation is used for one-to-one relationships. In the context of this research, conformance shows how constructs in the metamodel at M2-level can be instantiated to derive migration methods at M1-level and scenarios at M0-level. 2.5.2.6 Quality of Metamodels

The quality of a designed metamodel is an integral part of a metamodeling process. The model quality, defined in (Moody, 2005), is “the totality of features and characteristics of a conceptual model that bear on its ability to satisfy stated or implied needs” (p. 2). The following reviews the most commonly used frameworks for examining the quality of conceptual models, applicable to different modelling paradigms.

63


The framework proposed by Lindland et al. (Lindland et al., 1994) includes three principles (also called quality factors) that should be addressed in a model. Syntactic quality is with respect to the modelling language. Semantic quality examines the validity and completeness of the model with respect to a domain of interest and the scope of the model. The validity is concerned with correctness and the relevance of the model to the domain whereas the completeness is to check if the model makes all constructs about the domain. The third design principle, called pragmatic quality, is to assess how a model can be constructed, comprehended, and modified by its audience (Lindland et al., 1994). The pragmatic quality is determined by many properties such as quality of diagrams or text, icons and names, and the layout and closeness of the model to the domain. Some researchers have extended Lindland’s framework by introducing new design principles. The framework proposed by Stamper (Stamper, 1996) defines principles of (i) physical quality the availability of the model for its audience, (ii) empirical quality the extent to which a model can be evaluated on its graphics and readability, (iii) organisational quality the extent to which a model fulfils the goals of the organisation that using it, and (iv) social quality, how the model may be interpreted differently by different groups of audience. The framework suggested by (Moody, 1998), includes the following principles: (i) flexibility ease of modifying a model because of changes in the business in terms of cost and complexity, (ii) integrity, the extent to which business rules are enforced by a model. Such business rules determine what can be correct or not correct about a model, (iii) model integration assesses the level of consistency of the model’s format and naming with rest of organisational data, and (iv) implementability, how simple it is to implement a model within time, budget and technology constraints of a project. Paige and Brooke (Paige et al., 2007a) present a comparison of approaches to metamodeling with respect to a set of design principles. The study provides guidelines for developers of modelling languages to conduct a metamodeling endeavour and metamodel-based conformance. In (Paige et al., 2007a), the definition of proposed principles understandability, correctness, maintainability, and completeness are similar to frameworks reviewed above. Nevertheless, other principles such as tool construction,

64


tool-based validation and verification, and automation mainly relate to the availability of tools to support producing and verifying models. Finally, Krogstie et al. (Krogstie et al., 2006) mention that Lindland’s framework is too static in its view of factors and ignores modelling activities. The authors perform some theoretical work to improve the definition of the principles and suggest a change to a model may also change the problem domain directly. Their focus is the pragmatic quality principle, including concerns such as overall learning, local learning, and overall domain improvement. Table 2-6 summarises the identified principles from the frameworks reviewed. At a glance, it can be seen that the frameworks are common in suggesting principles completeness, understandability, and correctness.

65

Chapter 2. Literature Review Table ‎2-6 Different frameworks and their design principles for metamodels

(Lindland et al., 1994)

Syntactic quality Semantic quality

Design principle

Pragmatic quality

(Stamper, 1996) Physical quality Empirical quality Syntactic quality Semantic quality

(Moody, 1998)

(Paige et al., 2007a)

Correctness Completeness

Pragmatic quality Organisation quality Social quality

Understandability Simplicity

Correctness Completeness Maintainability Understandability Tool construction Tool-based Validation and verification Automation in multi-view consistency checking

Flexibility Integrity Integration Implementability

2.5.2.7 Related Work on Metamodeling in the Cloud Computing Literature

The literature pertinent to applying metamodeling in the cloud computing field varies in different streams. Table 2-7 presents a synopsis of the related research with key contributions. The majority of them focus on using metamodels to implement cloud applications. In the following, an overview of the most notable research in this area is provided. The first stream of metamodeling research concentrates on demystifying the technical architecture of cloud computing. Academic research such as (Hamdaqa, 2011, Liu et al., 2011, Zhang and Zhou, 2009, Zimmermann et al., 2013) and white papers published by major players of cloud computing such as IBM, HP, Oracle, and Cisco are subsumed under this stream. The second stream is about distilling and sharing practice knowledge for the green cloud. The metamodeling in (Procaccianti et al., 2014) is used to formalize a picture of how cloud data centres address the problem of reducing their energy footprint and carbon emission. In another work, Nowak et al. (Nowak et al., 2014) propose a metamodel of the green practice for all aspects of cloud-based business processes such as environmental impact, pollution, and waste in class of patterns. Dougherty et al.

66


(Dougherty et al., 2012) have proposed a metamodel-based auto-scaling resource management to reduce unnecessary idle cloud infrastructures. The third stream concerns quality aspects of cloud services. As an example, the metamodel developed by cloud accountability project (called A4Cloud) formulates knowledge about the none-functional properties of cloud services, and in particular, those that influence accountability of cloud providers (Nunez et al., 2013). The purported goal of this metamodel is to act as a language to describe cloud service accountability in terms of transparency, verifiability, observability, and liability. It allows derivation of metrics from a high-level model to a tangible and measurable one, enabling consumers to monitor the quality of cloud service providers. Developing a metamodel to represent and share domain concepts of cloud services certification process has been of the goals of European FP7 project on how a certificate is produced, what its content is, and how it is managed (Cimato et al., 2013). It conceptualizes the concepts involved during the certification phases and allows for defining different instances of certification models. A number of scholars report that the adoption of metamodels eases code refactoring of cloud applications. In this regard, the common feature of studies (Ardagna et al., 2012, Kopp et al., 2012, Wettinger et al., 2013) is to address the interoperability and portability of application across different cloud providers by providing a support for instantiation of application description into multiple cloud environments through using metamodel transformation techniques. This stream of studies uses feature models to model application variability and retransform them for a given target cloud platform. Capturing the common knowledge of designing cloud architecture has been a topic of discussion in (Fehling et al., 2012, Fehling and Retter, 2011), a catalogue of patterns for legacy source code refactoring is proposed to enable the use of cloud services. In the last stream in the software engineering, researchers have incorporated domainspecific languages (DSLs) for developing cloud applications, such as cloud risk modelling (Zech et al., 2012), cloud service compliance management (Brandic et al., 2010), cryptographic cloud computing (Bain et al., 2011), distributed data-parallel computing (Isard and Yu, 2009), cloud-mobile hybrid applications (Ranabahu et al., 2011), describing big data analytic algorithms for data analytics in the cloud (Weimer et

67


al., 2011), and automatically code generation for cloud applications (Sledziewski et al., 2010), to maximize SaaS application reusability (La and Kim, 2009). The central claim of these technical studies is on the seamless transformation of application codes to various cloud-specific platforms by using model transformation techniques. Finally, metamodel creation has received attention from IS scholars. The work presented in (Martens and Teuteberg, 2011, Keller and König, 2014) propose reference models to support organizations in managing and reducing risk and compliance efforts for cloud computing as a socio-technical artefact. The current research posits that metamodeling is a legitimate and well-suited theoretical lens to understand cloud computing. However, due to different viewpoints of metamodel creation in the literature, when it comes to design a metamodel to establish a methodological support for moving to the cloud, the research is less common.

68


Table ‎2-7 Summary of relevant research on metamodeling research in cloud computing

Scope Cloud architecture

Authors title

Developed metamodel (artefact) Metamodel of cloud computing applications

Unit of analysis

Key Contributions

Cloud application

A metamodel as cloud modelling language aiding developers to better understanding cloud application architectures. Demystifying the main constructs are incorporated in cloud migration including actors, architectural components, interactions between actors, and activities. Facilitating interoperability of cloud services, providing a reference point for mash-ups, and guidance on how to combine and interchange cloud services.

(Hamdaqa, 2011)

Demystifying cloud computing vocabularies, relations between them, and design elements

(Liu et al., 2011)

Conceptualization the of cloud computing architecture

Metamodel computing architecture

cloud enterprise

Enterprise architecture

(Lenk et al., 2009)

A hierarchical model of cloud computing technologies

Integrated cloud computing stack


(Tsai et al., 2010)

Combining the notions of cloud computing and service computing

Four layer cloud service computing architecture style


Proposing an open architecture for cloud service computing open which standards and ontology are embraced.

al.,

An overall architecture building blocks of big data cloud computing applications

Metamodel of big application architecture

Big data cloud applications

Supporting semantic analysis and program comprehension of service-oriented big data applications.

(Zhang and Zhou, 2009)

Standardization of a configurable and extensible cloud computing architecture model

Metamodel of principles of cloud computing architecture


Isolating the enterprise architecture from infrastructure enablement during cloud architecture design process by formulating architectural principles and modules.

(Procaccianti 2014)

Distilling knowledge of green practice for designing cloud infrastructures

Green cloud metamodel

cloud infrastructure

A metamodel formulating recurrent and reusable architectural tactics and goals and addressing the problem of reducing energy footprint in green cloud architectures. The metamodel can be used for the

(Zimmermann 2013)

Green Cloud

Focus

et

et

al.,

of

69

data


refactoring of enablement.

Cloud Services

Cloud application interoperability and portability

(Nowak et al., 2014)

Distilling knowledge of green practice for IaaS-based business processes

Green cloud metamodel

(Dougherty et al., 2012)

Capturing common features/requirements of virtual machines performed in cloud

(Nunez et al., 2013)

existing

applications

for

cloud

Business processes

A catalogue of green practice for designing green business processes. It aids developers to design virtual machines for execution of cloud-based business processes.

Metamodel-based auto-scaling resource management approach

IaaS-based virtual machine

Developers can express requirements such as energy consumption per hour and cost attribute for VM instances using an instantiable metamodel of common features of virtual machines. The metamodel optimizes energy consumption of cloud auto-scaling infrastructure to create greener computing environments that reduce emissions resulting from superfluous idle resources.

A language for describing and measuring accountability attributes of cloud service and providers

Metamodel of cloud services accountability

Cloud service

A language for describing none-functional properties of cloud services in terms of entities, evidence and actions. The language facilitates defining meaningful measures for accountability properties of cloud provider including transparency, verifiability, observability, liability, responsibility, attributability, and remediation.

(Cimato et al., 2013)

A language to express domain concepts of cloud service certification process

Metamodel of cloud services certification process

Cloud service

A unified metamodel for the defining of the security properties to be certified, the types of evidence underlying them, and the phases of the certificate lifecycle, as well as all mechanisms for instantiating supporting evidence.

(Ardagna et al., 2012)

Portability interoperability applications in clouds

Using model transformation techniques

Cloud application

Allowing developers to design application in a cloudagnostic way and instantiate it for different cloud environments. This way provides closed-loop between the run-time and design-time environments of application and triggers the dynamic deployment

and of multiple

70


of the application.

Cloud architecture design best practices Domain specific language

(Caballer et al., 2014)

Execution of scientific applications in cloud infrastructures

Using the concept of container to encapsulate programming model logic and the infrastructure needed to execute it in the cloud.

(Maximilien 2009)

Managing application deployment and cross-cloud interoperation

Cloud-agnostic APIs

(Kopp et al., 2012)

Business process interoperability and portability on multiple clouds

Extending BPMN with specific elements for transformation of business process to a specific platform

(Wettinger et al., 2013)

Model-driven management

High-level metamodel

(Fehling et al., 2012)

Formalizing best practice design of cloud-based application architecture

(Sledziewski 2010)

et

et

(La and Kim, 2009)

al.,

al.,

Scientific Cloud applications

Developer can adapt, deploy and execute parallel applications covering different programming models (such as Master/Slave, Parallel/MPI, MapReduce and Workflows) to the cloud backend.

Middleware architecture

A meta-model to model cloud platforms at an abstraction level to support application deployment and redeployment in the cloud.

Business Process

Providing automated modelling and transformation for planning, tailoring and deploying composite business processes on different IaaS providers and workflow engines. Modeller defines abstractly what kind of service should be invoked without concrete references to services. Instantiation information such as virtual machines is then added by Plan Portability APIs.

Cloud application

A model-driven support for specifying configuration templates in a higher level of abstraction including topology template, node types, and relationship types in application configuration.

A pattern language

Cloud application

A language to describe common design patterns for cloud computing architecture design.

Increasing productivity of application development for Cloud

DSL for describing cloud application

Cloud application

A domain language allowing developers to generate high-level representation of an application and to generate application codes to be deployed in the cloud.

Maximizing the reusability

Model-driven

SaaS application

Defining a lifecycle including guidelines to model a

configuration

configurative

71

SaaS


and customizability of SaaS applications

development process

(Zech et al., 2012)

A central model from which risks related to the cloud deployment can be deviated and analysed.

DSL for generating deployment model of application in the cloud

Cloud application

Allowing developers to describe cloud deployment model by their functional and none-functional security-related properties. The defined model then is enriched by a vulnerability knowledge based to do security analysis. The language facilitates expressing the variety of deployment models.

(Brandic et al., 2010)

Simple and flexible compliance information management

DSL for specifying compliance requirements of cloud consumers

Cloud application

A language to express user requirements and compliance level agreements such as, security restrictions, privacy, trust, and compliance level agreements. It supports semi-automatic deployment of applications in the cloud.

72

high-level architecture of SaaS including features, communalities, variation points and scope of variations. Cloud platform specific information is added to application models when application is to be deployed in a specific cloud platform.


2.5.3 An Overview of the Proposed Framework The following subsections firstly synthesises key design principles to develop and evaluate the proposed framework in Section 2.5.3.1 and then present the components of the framework and their role in sections 2.5.3.2, 2.5.3.2.1, and 2.5.3.2.2. 2.5.3.1 Development of Design Principles for the Proposed Framework

This section synthesises a few design principles as fundamental requirements that are expected to be addressed during the development and evaluation of DSMLs (e.g. metamodels and models), in particular, the proposed framework in this research. Results of the evaluation demonstrate the proposed framework based on the principles that provide a methodological foundation including support for creating, configuring, and sharing customised methods for different scenarios. The development of the design principles are originated from the existing DSML literature, mainstream metamodeling frameworks presented in Section 2.5.2.6, and key concerns of the cloud migration reviewed in Section 2.2. Design principles proposed in this section are testable propositions and further are employed to develop and evaluate the components of the proposed framework. For instance, researchers can evaluate the adherence of a modelling framework to design principles using case studies (Antkiewicz et al., 2009b, Cuadrado and Molina, 2009). Design principles and their connection with the context of this research are discussed in the following. One concern during creating a DSML (e.g. metamodels and models) is the level of its completeness, that is, the extent to which the metamodel can make different kinds of statements required in the domain (Lindland et al., 1994). Mitchell states that a language designer should discover key constructs in the problem domain and ensure they are modelled and representable during system development lifecycle (Bain et al., 2011). A designer may tend to include many domain constructs in a DSML. However, achieving valid completeness may not be feasible. In addition, the domain may contain many constructs that are irrelevant and, hence, out of the scope of the DSML purpose. Overemphasising on a DSML with many constructs is a worth

73


practice. Completeness can be considered in terms of an appropriate balance between generality and specificity is an important factor in the successful development of a DSML. A DSML can be either too generic or too specific to the domain and in some cases both. Steven et al. (Kelly and Pohjonen, 2009) suggest to include common core constructs in the domain. They mention, “DSML isn’t about achieving perfection, just something that works in practice. It will always be possible to imagine a case that the language can’t handle. The important questions are how often such cases occur in practice, and how well the language deals with common cases” (p. 23). They further advise that in order to avoid analysis paralysis, one should concentrate on the core cases and build a prototype language for them. Defining a threshold for a DSML completeness depends on the application context and, although is not easy to quantify, it can be when the model is detailed enough according to the purpose of modelling and further modelling is less beneficial (Lindland et al., 1994). This can be examined, for example, by tracing proposed DSML constructs to real word models (Othman et al., 2014) or existing counterpart models (Beydoun et al., 2009). When viewing the cloud migration from a methodological perspective, a good coverage on core activities and expected outputs that are incorporated into the migration process is important. The key concerns, as presented in Section 2.2, are a good yardstick to get a feasible completeness of functional and non-functional methodological requirements to be addressed by an ideal cloud migration method. The concerns are Analysing Organisational Context (C1), Understanding Cloud Migration Objectives and Requirements (C2), Proper Cloud Migration Planning (C3), Understanding Legacy Applications (C4), Target Cloud Platform/Service Selection

(C5),

Re-Architecting

Legacy

Applications

(C6),

Environment

Configuration (C7), Testing (C8), and Tailoring (C9). This leads defining the first design principle: Design Principle 1 (DP1): Originated from the design principle Completeness (Section 2.5.3.1), the proposed framework should capture all important and sound methodological constructs that are relevant for the incorporation into a typical process of the legacy application migration to the cloud.

74


Developing a DSML needs a good knowledge of the domain. This implies that a language designer should think abstract and take his/her noise above the system code level, programming, and technical-oriented notions in the domain (Kelly and Pohjonen, 2009). He/she should be able to produce good vocabularies for the domain that are understandable and interpretable by the audience of DSML, which is referred to as “Audience-domain appropriateness” (Lindland et al., 1994). A suitable DSML allows for minimum multiple interpretations by audiences. Ambler (Ambler, 2005) states that for better understandability of a model, it should be kept simple and avoids details not necessary for modelling. Excessive emphasis on incorporating technical or programming concepts into a DSML, although, is useful they should not be defined as core constructs otherwise they impede the expressivity power of the DSML and lead to a poor abstraction level (Kelly and Pohjonen, 2009). As mentioned earlier in Section 2.5.2.6, the understandability of a model is determined by many properties such as quality of diagrams or text, icons and names, and the layout and closeness of the model to the domain (Lindland et al., 1994). In the context of the current research, an understandable model can clarify the meaning of activities in order to understand what cloud service is supposed to provide and what service consumer need to consider or implement to utilize advantages of cloud computing such as availability and scalability. In this research, the naming and terminologies that proposed for the solution are results of synthesising the content in the cloud computing literature. The second design principle is formulated as the following: Design Principle 2 (DP2): Originated from the design principle Understandability (Section 2.5.3.1), the definitions and names of constructs in the framework should be comprehensible by domain experts. A DSML contains names, definitions, relationships among constructs and interpretable by human and computer for the purpose of generation and analysis (Moody, 1998, Paige et al., 2007a). The correctness can be checked either by examining the DSML against existing domain models or domain experts. A metamodel for cloud migration process needs to specify relationships among operations, which can be in the form of a sequence, input/output, association, or aggregation. An example may illustrate this point. According to the discussion in

75


Section 2.2.6, a key concern in a cloud migration scenario is potential incompatibilities (e.g. APIs) between legacy systems and cloud services. This implies a sequence in the cloud migration process in the sense that once a decision on the cloud platform selection is made, the next step is to identify and analyse incompatibilities between these two platforms. In this research, the relationships defined in the framework are based on the recommendations in the cloud computing literature. The second design principle is defined as the following: Design Principle 3 (DP3): Originated from the design principle Correctness (Section 2.5.3.1), the notation and relationships among the constructs in the framework should be correct and meaningful. A DSML should support changes and improvements so that it can be customised into a new domain and continuously evolved according to upcoming domain requirements. The more a DSML is close to the problem domain, the more simple its customisation, maintenance, and evolution (Jonkers et al., 2006). DSML includes a set of generic constructs, which are abstract enough and common to represent the domain. Customised models from DSML can then be used to generate software systems. Converting the above point to the context of this research, the proposed framework, which is supposed to a representation for the cloud migration process, should be tailorable to meet requirements of migration scenarios. This is due to the fact that mentioned in Section 2.2.9. Cloud migration scenario to move legacy applications to the cloud may have different characteristics such as system workload for moving to the cloud, chose of migration type and cloud services. Hence, there is no single applicable method for all scenarios. In situations like this, designing customisable methods or configuring existing one that fit characteristics of migration scenarios is pivotal for successful adoption of the cloud computing. With respect to this, the fourth design principle is defined as follow. Design Principle 4 (DP4): Originated from the role of metamodels in the method tailoring (Section 2.5.3.1), the framework should enable method designers in standardising, sharing, and tailoring migration methods for specific scenarios.

76


2.5.3.2 MLSAC Framework

An architecture framework as defined by (Emery and Hilliard, 2008), establishes a common practice for creating, interpreting, analysing, and using architecture descriptions within a particular domain of application or stakeholder community (p. 43). Such a framework is a semi-complete application which offers a number of familyrelated components and mechanisms which can be reused, customised, and extended by its user to form complete applications for a particular domain (Schmidt and Buschmann, 2003, Fayad et al., 1999). The framework components standardise certain design decisions and collaborate to create customisable application-independent reusable solutions. A well-designed architecture framework is the one that employs the domain knowledge, the common abstractions of multiple concrete target domains, and supports a set of concerns that need to be addressed in the development of an application (Schmidt and Buschmann, 2003). The proposed framework leverages proven approaches in IS and software engineering disciplines mainly metamodeling (Section 2.5.2.2) to achieve its objectives. It will serve as a first endeavour that explicitly and intensively supports the methodological aspect of the cloud adoption by addressing key concerns of the cloud migration process (Section 2.2). The framework provides a full list of important domain constructs that are uncovered, harmonised, and will be reused to represent, create, tailor, and maintain domain specific cloud migration methods. Nevertheless, the framework is generic and grounded on an embrace and extends philosophy. Based on the methodological support implications for moving legacy applications to cloud environments (Section 1.2) and along with limitations in the existing literature to adequately address this gap (Section 2.4), this section introduces a solution framework called Migration Legacy Software Applications to the Cloud (MLSAC). MLSAC is expected to provide a generic cloud migration process model, which can be reused and tailored for specific migration scenarios at hand (Figure 2-14). Research motivation (Section 1.2) and the knowledge gaps in the literature (Section 2.4) highlight the need for such a systematic framework. The MLSAC is useful for (i) both IS and software engineering academia and practitioners seeking an understanding of a typical process

77


for legacy application migration to the cloud (ii) creating, standardising, tailoring, and publishing situational cloud migration methods. Derivation of the framework components is based on the resulting design principles (Section 2.5.3.1) that are expected to be addressed by a proper methodological solution for the cloud migration. The aim of providing process guidance is to provide clear directions that have to be executed, by either cloud service provider or consumer, and incorporated into existing methods in which cloud computing characteristics are not supported. Three design principles DP1, DP2, DP3 are in relation to this point. On the other hand, the process guidance, which represents overall migration process, should be customised based on the dynamically changed requirements of migration scenario or service consumer. This is related to the DP4. Therefore, the proposed framework includes two integrated core components: (i) MLSAC Metamodel is a generic process model that captures important domain constructs for the incorporation into the cloud migration process. This component concerns DP1, DP2, and DP3. The metamodel enables representing and maintaining migration methods in a standardised, interoperable, and wellstructured manner. It is also enriched with guidelines illustrating situations in which a construct is required and its sequence in the migration process. (ii) MLSAC Method Tailoring is a step-by-step procedure aiding a method designer to instantiate the metamodel to create, configure, and maintain situational migration methods. This component is related to DP4. The idea behind these two components is consistent with the method engineering idea. For example, Karlsson (Karlsson, 2013) proposed a method configuration environment, named MC Sandbox, including a repository to capture method requirements through the use of method-user-centred method configuration procedure. Figure 2-14 shows a conceptual view of MLSAC framework that is elaborated in the following subsections.

78


Figure ‎2-14 A conceptual view of the MLSAC framework

2.5.3.2.1

MLSAC Metamodel Component

This component includes essential constructs associated with the process of moving to cloud environments. They are a result of harmonisation and reconciliation of different constructs which appear in the cloud migration literature. As shown in Figure 2-15, the metamodel occupies M2-level of the OMG metamodeling framework (Section 2.5.2.4). It is expected that migration solutions (presented in Table 2-3), which are positioned at M1-layer (Figure 2-15), can be represented through using the metamodel’s constructs. From this angle, the MLSAC metamodel describes required constructs that a cloud migration method is based. Although the metamodel is introduced as the component of the MLSAC framework, it can be separately used as a resourceful knowledge repository of the cloud migration process. This component is delineated in Chapter 4.

Figure ‎2-15 The position of the MLSAC metamodel in OMG metamodeling framework, reproduced from (Karagiannis and Kühn, 2002)

79


2.5.3.2.2

MLSAC Method Tailoring Component

The second component of the framework is a procedure to create, configure, and publish bespoke cloud migration methods through reuse and enhancing the MLSAC metamodel constructs. The proposed procedure is inspired by the idea of the method engineering approach (Section 2.5.2.3). It starts with specifying the parameters of a cloud migration scenario and then identifying relevant metamodel constructs, commencing with a high-level method and recursively configuring it to meet expected migration scenario. The procedure is demonstrated through interactive forms and the repository as described in Chapter 8.

2.6

Summary

This chapter reviewed the fundamental concepts that are used in the next chapters such as legacy applications, cloud computing, migration types, cloud migration process, and methods. A list of key concerns attributed to the cloud migration process was discussed in Section 2.2. The chapter reviewed ten different cloud migration methods available in the literature. This review revealed that the existing methods are deficient regarding all concerns C1 to C9, providing a unified view of the cloud migration process existing metamodels, and a support of tailoring. By acknowledging these gaps in the literature, the chapter presented an overview of the metamodeling as a viable solution to address the literature gap stated in Section 2.4. The chapter presented terminologies related to the metamodeling such as model transformation, design principles related to metamodeling, and some applications of metamodeling in the cloud computing field. Finally, a solution framework that fulfils the objective of this research was proposed.

80

Chapter 3. Research Methodology

Chapter 3.

Research Methodology

The only reason that it takes me seven years to do stuff is because I just don't really have a plan - Fiona Apple A research methodology is a critical part of conducting any research program because it underpins an overall big picture of the research process, tasks, and steps to carry out (Dubé and Paré, 2003, Benbasat et al., 1987). Section 3.1 justifies and presents Design Science Research (DSR) as an overall research paradigm including research tasks to conduct the current study. This chapter continues with relevant tasks to fulfil the framework in Section 3.2. This chapter ends in Section 3.3.

3.1

Research Philosophy

This research addresses the knowledge gap explicated in Section 2.4 by proposing an architecture framework as an IT artefact. Section 3.1 introduces the DSR, which is used to accomplish the proposed framework introduced in Section 2.5.3. Next, Section 3.1.2 discusses how the DSR is applied in this research. 3.1.1 Design Science Research The research philosophy concerns the nature and development of knowledge (Cooper et al., 2003). According to (Gregor, 2006) there are a few underlying research philosophies in IS field, described in the following. Positivist research (Orlikowski and Baroudi, 1991) is premised on the existence of a priori fixed relationships within phenomena, which are typically investigated structured instrumentation. Studies based on this philosophy perform theory testing to improve predictability of the phenomena. A positivist study is characterised by formal propositions, quantified measures of variables, hypotheses testing, and drawing inferences about the phenomena on the basis of sample data from the population.

81


Interpretive research (Orlikowski and Baroudi, 1991) investigate a phenomenon in association and subjective meanings as they interact with it. In other words, interpretivists attempt to understand the phenomenon via analysing the relativistic meanings that participants assign to them. Generalization through statistical analysis of population is not the intention of the researcher, rather the aim is to achieve a deeper understanding of the structure of a phenomenon. Critical research (Myers and Klein, 2011) studies are concerned with social issues such as freedom, power, social control, and values with respect to the development, adoption, and impact of information systems. Critical research can help IS professionals understand and improve their practice whilst for IS scholars it uncovers, criticizes, and changes prevailing assumptions in the literature. Another philosophical research perspective is the design science research (DSR) (Vaishnavi and Kuechler, 2004, Hevner et al., 2004, March and Smith, 1995, Gregor, 2007), which inquires to create “what is effective” (Hevner et al., 2004) (p. 98). Within this setting, DSR is proactive with respect to technology and focuses on creating innovative IT artefacts that help organisations to cope with problems related to information processing. As mentioned, an essential feature of the DSR paradigm is to produce a viable artefact that addresses a relevant solution to an unsolved problem. Such an artefact may be in the form of a software system, formal logic, models, methods, and informal language descriptions (Hevner et al., 2004). The current research believes that DSR is a suitable research philosophy for achieving the goal of this study. The reason is that the outcome of this research is methodological support for cloud migration; hence, this research seeks to prescribe and innovate an IS artefact. Such inquiry fits into the world of “design” in its nature and a tangible product that can be sensed by the world (Hevner et al., 2004). The importance of the DSR has been well recognised in IS literature due to its prescriptive nature in creating artefacts in any areas where problems are still unsolved (Vaishnavi and Kuechler Jr, 2007, March and Smith, 1995). A rigorous research methodology is required to conduct DSR so that IS and software engineering reviewers can recognise and assess the research results (Vandenbosch and Higgins, 1995, Peffers et al., 2008). Looking at influential prior work by (Hevner et al.,

82


2004, Peffers et al., 2006, Vaishnavi and Kuechler Jr, 2007, Nunamaker Jr and Chen, 1990, von Alan et al., 2004, Gregor and Jones, 2007), a comprehensive DSR should at least covers the phases Identify Problem and Define Objectives of a Solution, Design, Evaluate, and Implement as described in the following. The first phase, Identify Problem and Define Objectives of a Solution, is to define a specific research problem and justify the value of creating a solution. In the Design and Develop Phase, an artefactual solution which embeds the research contribution is created with respect to expected functionalities. In addressing the problem, kernel theories or approaches from inside or outside IS and software engineering disciplines that inform the artefact creation can be borrowed to find the solution (Gregor and Jones, 2007). Once designed, the artefact efficacy to solve problem instances is appraised in the Evaluate Phase, which can be conducted in different ways such as experiments, case studies, simulation, proof, or other appropriate techniques (von Alan et al., 2004). Accordingly, any evidence showing the worthiness of the artefact is reported and discussed (Gregor and Hevner, 2013). A feature of DSR is the iterative or cyclical refinement of the artefact’s through Design and Evaluate phases to improve the artefact efficacy (Kuechler and Vaishnavi, 2004). The feedback collected from each evaluation is used to refine the artefact to its next version and subsequently for the next iteration. In other words, the evaluation of the artefact is tightly coupled with the Design Phase. This iteration cycle is repeated to finely-tune the artefact. The Implement Phase develops a proof of concept prototype based on the proposed artefact to demonstrate its usefulness and applicability. In this phase, the prototype is used to solve instances of the problem. 3.1.2 Research Philosophy Used in This Thesis Acknowledging that DSR is an appropriate way to fulfil the objective of this research, the following subsections discuss the way DSR is used to conduct the current research. 3.1.2.1 Phase 1— Identify Problem and Define Objectives of a Solution

This phase is described in the literature review (Chapter 2). The cloud migration

83


literature lacks a consolidated reference process model which covers the essential concerns identified in Section 2.2. In addition, it was noted that existing methods are narrow in focus and present heterogeneous viewpoints of the same cloud migration process while there is no established correspondence among them. As such, it is hard to get an overall understanding of a typical cloud migration process. Furthermore, there is a dearth of research that suffices the method tailoring to create bespoke methods to suit a given cloud migration scenario. 3.1.2.2 Phase 2— Design and Develop

In a bid to address the problems stated in sections 1.2 and 2.4, MLSAC is proposed in Section 2.5.3. Among different theoretical lens that have been employed to understand the nature of cloud computing adoption, a suitable approach through which the proposed framework is designed is the metamodeling described in Section 2.5.2.4. Recall from Section 2.5.3.1, four design principles are expected to be satisfied by this framework. The first design principle is defined in the following. —Design Principle 1 (DP1): Originated from the design principle Completeness (Section 2.5.2.62.5.3.1), the proposed framework should capture all important and sound methodological constructs relevant for incorporation into a typical process of the legacy migration to the cloud. In the context of this research, the key concerns, presented in Section 2.2 are used as means to provide feasible completeness of functional and non-functional methodological requirements to be addressed by an ideal cloud migration method. These concerns are Analysing Organisational Context (C1), Understanding Cloud Migration Objectives and Requirements (C2), Proper Cloud Migration Planning (C3), Understanding Legacy Applications (C4), Target Cloud Platform/Service Selection

(C5),

Re-Architecting

Legacy

Applications

(C6),

Environment

Configuration (C7), Testing (C8), and Tailoring (C9). The second design principle is defined as: —Design

Principle

2

(DP2):

Originated

84

from

the

design

principle


Understandability (Section 2.5.2.62.5.3.1), the definitions and names of constructs in the framework should be comprehensible by domain experts. In this research, the naming and terminologies proposed for the solution are results of synthesising the content in the cloud computing literature. For the second design principle, the framework defines activities to provide an understanding of what cloud computing is expected to provide and what a service consumer needs to implement to utilize advantages of cloud computing, such as availability and scalability. The framework synthesises the names and terminologies in the cloud computing literature. —Design Principle 3 (DP3): Originated from the design principle Correctness (Section 2.5.2.62.5.3.1), the notation and relationships among the constructs in the framework should be correct and meaningful. For the third design principle, the relationships in the framework are based on recommendations in the cloud computing literature. An example may clarify this matter. As mentioned in Section 2.2.6, when a cloud platform is chosen, the next step is to identify possible technical incompatibilities between legacy systems and a target cloud platform. Relationships can be in the form of sequences, inputs/outputs, associations, or aggregations. —Design Principle 4 (DP4): Originated from the role of metamodels in method tailoring (Section 2.5.2.62.5.3.1), the framework should enable method designers to standardise, share, and tailor migration methods for specific scenarios. Recall from Section 2.2.9, a scenario for moving to the cloud may have different characteristics such as system workload, choice of migration type and cloud services. For successful cloud adoption, it is important to design new methods or tailor existing ones to fit characteristics of the scenario. This research defines several tasks for this phase in Section 3.2. 3.1.2.3 Phase 3— Evaluate

This phase examines the quality of proposed design artefact. Rigorous evaluation is an

85


important part of DSR effort which justifies the usefulness and contribution of the research outcome. The evaluation is performed via instantiation of a design artefact to illustrate its feasibility in resolving real-world problems. This research uses design principles DP1, DP2, DP3, and DP4, presented in Section 3.1.2.2, for the evaluation of MLSAC framework. Adherence to design principles is evaluated through (i) a Web-based survey (Chapter 5), (ii) case studies (Chapter 6), (iii) domain expert review (Chapter 7), and (iv) the implementation of a system prototype (Chapter 8). For the purpose of the first evaluation, DP1 is examined through a Web-based survey questionnaire of experienced cloud practitioners and researchers. The purpose of this evaluation is to assess whether the constructs in the metamodel component are perceived as important by respondents. This is examined through a statistical test to determine if the mean of experts’ responses is different from a particular threshold. For the second evaluation task, DP1 and DP3 are used to appraise the expressivity power of the metamodel component to represent real-world cloud migration scenarios. For the third evaluation, DP1, DP2, and DP3 are used to evaluate the framework in terms of coverage of key domain constructs, validity of relationships defined in the framework, and understandability of notions and definitions. Finally, in the fourth evaluation, the second component of the framework, i.e. the tailoring procedure, is evaluated through example scenarios and feedback provided by domain experts. Results from evaluations are used to refine the framework, which subsequently leads to its next improved version. 3.1.2.4 Phase 4— Implement

The applicability and usefulness of the framework are demonstrated in this phase. A prototype is implemented which enables method designers to utilise the framework for creating, maintaining, and sharing customised cloud migration. The applicability of the framework is shown by some examples and feedback from domain experts.

3.2

Research Tasks to Fulfil the Framework

Figure 3-1 shows the relationships between phases in general DSR process and the

86


current research. In this figure, the phases are decomposed into tasks to realise the proposed MLSAC framework. These tasks are defined in the following subsections.

Figure ‎3-1 Phases and research tasks for this research

3.2.1 Development of the MLSAC Metamodel In this task, a generic process model of moving legacy applications to cloud environments is developed. DP1 and DP3 are targets of this task. The first step is to identify key constructs relevant to the cloud migration domain (Section 4.1.1). This research uses the studies identified in Table 2-3 as a knowledge source for the metamodeling purpose. It includes a variety of existing studies in the literature related to the cloud migration. The next steps are to extract constructs from the knowledge source (Section 4.1.2), create overarching constructs (Section 4.1.3), harmonise constructs’ definitions (Section 4.1.4), organise constructs into phases (Section 4.1.5), define relationships among them (Section 4.1.6), to define relationships between migration types and the metamodel constructs (Section 4.1.7), and to cross-check the metamodel against existing migration methods (Section 4.1.8). The output of this task is the first version of the metamodel called, version 1.0. Chapter 4 presents executing and results of this task.

3.2.2 Development of the MLSAC Tailoring Procedure This task is concerned with DP4. In this task, the second component of the MLSAC framework is designed. The procedure relies on the metamodel component and is accomplished in a top-down fashion. It starts with specifying cloud migration scenario parameters, the instantiation of the metamodel to a specific method, fine-tuning the method to meet the requirements of an expected migration scenario, and finally

87


publishing it. The results of this task are presented in Chapter 4. 3.2.3 Evaluation (I) of MLSAC Framework This task is concerned with DP1 and aims to assess the importance of the defined domain constructs in the MLSAC metamodel. A Web-based survey questionnaire of experienced cloud practitioners and researchers is performed in order to assess the perceived importance and relevance of the constructs in the metamodel. Respondents are also asked to justify their responses and suggest additional constructs that are missing in the metamodel. The task defines steps including survey design, pilot survey, data collection, analysis of collected responses, and reporting the results. Chapter 5 reports the execution and results of this task. 3.2.4 Evaluation (II) of MLSAC Framework This task is concerned with DP1 and DP3 and appraises the expressivity power of the metamodel to model real-world cloud migration scenarios, which are positioned in L0level of MOF modelling framework. As the MLSAC metamodel is generic and platform-agnostic, it is expected to generate real-world migration processes. The task, described in Chapter 6, includes steps identifying case study, analysing the metamodel coverage for migration scenarios, and refining the metamodel. 3.2.5 Evaluation (III) of MLSAC Framework The objective of this task is to obtain qualitative opinions from a panel of academic and industry domain experts about the adherence of MLSAC metamodel to DP1, DP2, and DP3. As explained in Chapter 7, the received feedback from each expert is analysed in order to refine the metamodel to the next version. The new version of the metamodel is further checked and confirmed by experts. Chapter 7 documents the results of performing this task. 3.2.6 Using the Prototype to Perform Method Tailoring This task examines MLSAC tailoring procedure in relation to DP4 used to instantiate

88


and configure the metamodel for particular migration scenarios. A prototype of MLSAC framework is implemented to show how the tailoring procedure facilitates the standardisation of migration methods across the cloud community as well as help domain-experts

to

design,

configure,

and

share

situation-specific

migration

methods. Chapter 8 introduces the prototype system and the evaluation of the MLSAC tailoring procedure. 3.2.7 Getting Feedback From Domain Experts The purpose of this task is to collect qualitative feedback on how well MLSAC framework works in terms of DP1, DP2, DP3, and DP4. Experts work with a prototype, run tailoring procedure, and express their opinions on the framework. The results of this task are reported in Chapter 8.

3.3

Summary

This chapter introduced and justified DSR as an overall research framework to fulfil the objective of this research. The proposed MLSAC framework comprises two components that from the backbone, a generic process metamodel and a tailoring procedure. The details of DSR programme in this research, including the necessary tasks were described. Table 3-1 summarises the research tasks carried out in this research and their objectives in relation to the design principles DP1, DP2, DP3, and DP4. The next chapters detail these research tasks and their results.

89

Chapter 3. Research Methodology Table ‎3-1 Summary of the research tasks and their objectives regarding the design principles

Research Task Development of the MLSAC Metamodel Development of MLSAC Tailoring Procedure Evaluation (I) of MLSAC Framework Evaluation (II) of MLSAC Framework Evaluation (II) of MLSAC Framework Using the Prototype to Perform Method Tailoring Getting Feedback From Domain Experts

90

DP1 √ √ √ √ √

Design principles DP2 DP3 √ √ √ √ √ √ √

DP4 √ √ √

Chapter 4. Development of the MLSAC Framework

Chapter 4.

Development

of

the

MLSAC

Framework

Research is creating new knowledge - Neil Armstrong This chapter aims is to develop the initial version of the MLSAC framework components. It divided into two main parts: the first part (sections 4.1 and 4.2) documents the steps and results of task Development of the MLSAC Metamodel, as defined in Section 3.2.1. The second part (Section 4.3) reports results of executing task Development of the MLSAC Tailoring Procedure (Section 3.2.2) and defines the steps to be taken to instantiate the metamodel to create bespoke methods for given migration scenarios.

4.1

Development of MLSAC Metamodel

As mentioned in Section 2.5.2.4, metamodeling is a complex process and demands sufficient and knowledge of a problem domain that might be fragmented and unstructured (Sánchez-Cuadrado et al., 2012, Cicchetti et al., 2011). To create the MLSAC metamodel in a rigorous way, the general guidelines introduced in Table 2-5 were utilised in an iterative process that included the following sequential steps (Figure 4-1). First, a knowledge source was prepared and constructs related to the migration concerns were extracted (described in Section 2.2). This includes Understanding Organisational Context (C1), Understanding Cloud Migration Objective and Requirements (C2), Proper Cloud Migration Planning (C3), Understanding Legacy Application (C4), Target Cloud Platform and Cloud Service Selection (C5), ReArchitecting Legacy Application (C6), Environment Configuration (C7), and Testing (C8). The constructs were grouped and refined based on the concerns, their similarities, and context, resulting in producing the essential constructs of the metamodel. Having harmonised construct definitions, the constructs were organised into phases (Step 4).

91


Finally, relationships among constructs and the migration types (Section 2.1.3) were specified (Step 5 and Step 6), as depicted in Figure 4-1. The following elaborates each of the above steps.

Figure ‎4-1 Steps in the development of MLSAC metamodel

4.1.1 Step 1—Preparing Knowledge Sources for Metamodel Creation A metamodeling endeavour needs a collection of models relevant to the domain of interest. This research uses 75 relevant studies (Section 2.2) identified from the cloud migration literature as the main knowledge source to create the target metamodel. They were collected from various sources such as journals and conferences and provided a broad knowledge about the cloud migration domain. These studies were presented in Table 2-3.

92


4.1.2 Step 2—Extracting Constructs from the Identified Sources In this step, all constructs and their definitions were manually identified and extracted from the knowledge source, including following concepts: (i)

Task: a discrete and small unit of migration work that IT developers may perform to achieve one or more specified goals,

(ii)

Work-Product: a tangible artefact produced during the migration process and used by other tasks,

(iii)

Principle: a design consideration that should be taken into account during cloud application design.

(iv)

Phase: a logical concept to manage the complexity of migration process and classify task and work-product constructs. It represents a particular period of a migration scenario.

Inspired by the guidelines introduced by (Ramsin and Paige, 2008) and specialised for the context of this research, the following criteria were used to identify and extract constructs from the knowledge source: (i) Criterion 1: A construct should be related to one or more concerns described in Section 2.2; (ii) Criterion 2: A construct should be sufficiently generic to a variety of cloud migration scenarios and independent from a specific cloud platform or application domain. The full text of each paper was analysed to identify constructs. With respect to criterion 1 and 2, constructs that were too general or belonged to general software engineering were not extracted as they were deemed out of the scope of this research. These included constructs related to umbrella activities such as risk management, project management, quality assurance, configuration management, and measurement (Pressman, 2005). The output of this step was a list of 426 constructs along with their definitions. Table 4-1 shows an example of how constructs were identified from the studies [S3] and [S9]. The full output of this step is presented in Appendix B. The examples below illustrate how this step was conducted.

93

Chapter 4. Development of the MLSAC Framework Table ‎4-1 Extracted construct from studies [S3] and [S9]

Study ID

[S3]

[S9]

Identified constructs 1) Establishing the Context 2) Modernising the Software Architecture 3) Modernising Data 4) Managing Non-Functional and QoS Requirements in the Cloud 5) Verification and Validation in the Cloud 6) Verifying the Scalability of Applications 1) Requirements Identification 2) Identification of Potential Cloud Hosting Environments 3) Identification of Potential Architecture Solutions 4) Evaluation of Cloud Environments for Cloud Specific Quality Attributes 5) Analysing Application Compatibility With Potential Cloud Environments 6) Evaluation of Proposed Solutions and Effected Components Against Target Platforms 7) Implementation and Refactoring 8) System Requirements 9) Finalised Design Decision and Modified System Architecture 10) Selected Cloud Environments 11) Trade off Analysis of Cloud Environment 12) Trade off Analysis of Quality Attributes Cloud

Source of Concern C1 C6.1 C6.6 C6.1

Total

6

C8 C8 C2 C5 C6.1 C5 C6.4.1, C6.4.2, C6.4.3 C8

12

C6.4.1, C6.4.2, C6.4.3 C2 C6.1 C5 C6.1 C6.1

As the first example, Chauhan’s method (denoted by S9 and described in Section 2.3.1) is a process model resulting from an experience gained in moving from an Open Source System (OSS) to two different cloud environments, i.e. Amazon Web Services and Google App Engine. This method has been incrementally developed by formalising the migration process, including useful guidelines based on observations and lessons learned from these two cases. By applying criteria 1 and 2, twelve constructs were identified from this method as follow: (1) Requirements Identification,(2)

Identification of Potential Cloud Hosting

Environments, (3) Identification of Potential Architecture Solutions, Evaluation of Cloud Environments for Cloud Specific Quality Attributes, (4) Analysing Application Compatibility With Potential Cloud Environments, (5) Evaluation of Proposed Solutions and Effected Components Against Target Platforms, (6) Implementation and Refactoring, (7) System Requirements, (8) Finalised Design Decision and Modified System Architecture, (9) Selected Cloud Environments, (10) Trade-off Analysis of Cloud Environment, (11) Trade-off Analysis of Quality Attributes Cloud, and (12)

94


Implementation. Another example is REMICS [S3], which is based on a model-driven approach and includes five constructs: (1) Establishing the Context, (2) Modernising the Software Architecture, (3) Modernising Legacy Data, (4) Managing non-functional and QoS Requirements in the Cloud, (5) Verification and Validation in the Cloud, and (6) Verifying the Scalability of Applications. Furthermore, definitions of constructs were also extracted from the source papers. An excerpt of the extracted definitions from [S3] and [S9] is presented in Table 4-2. Full definitions of the extracted constructs are shown in Appendix C. Table ‎4-2 An example of extracted constructs from [S3] and [S9]

Construct Analysing Application Compatibility With Potential Cloud Environments

Source ID [S9]

Evaluation of Cloud Environments for Cloud Specific Quality Attributes

[S9]

Evaluation of Proposed Solutions and Effected Components Against Target Platforms Finalised Design Decision and Modified System Architecture

[S9]

Identification of Architecture Solutions

Potential

[S9]

Identification of Potential Cloud Hosting Environments

[S9]

Implementation

[S9]

Implementation and Refactoring

[S9]

[S9]

Definition from the Source Paper “Application is analysed to assess its compatibility with the potential cloud computing environments. This activity purports to identify the changes required to resolve incompatibility issues between a system and a target platform. For example, it may be the case that a target PaaS cloud does not support frameworks or specific technologies being used by an application. If such issues are identified, then these need to be resolved first” “Analysing the potential cloud platforms for specific features of a provided service, e.g., SaaS that needs to be supported by a hosting platform” “Identify any conflict between a proposed solution and a chosen cloud environment” “Describing compatibility map of a proposed solution against a target cloud environment as well as a set of quality characteristics to be supported by a cloud environment” “The proposed solutions are then analysed for their advantages and disadvantages with respect to the quality attributes. At the end of this activity, a solution is selected that best satisfies the functional as well as quality requirements. In some cases, it may not be possible that one solution satisfies all the requirements. Then a tradeoff analysis is performed and an optimal solution is devised that satisfies the most important requirements” “Identify a set of potential cloud computing platforms based on a project’s nature, data confidentiality and sensitivity requirements, budget constraints and long-term organisational objectives” “Re-factoring the designed solutions for migrating a system to be deployed on a target cloud environment” “Implementing (and/or re-factoring) the designed

95


Requirements Identification

[S9]

Selected Cloud Environments

[S9]

System Requirements

[S9]

Trade off Analysis of Cloud Environments Modernising the Architecture

[S9] Software

[S3]

Verification and Validation in the Cloud

[S3]

Verifying the Applications

[S3]

Scalability

of

solutions for migrating a system to be deployed on a target cloud environment” “Identification of the business requirements that initiate the migration process and elaborating the main motivation for migration and the objectives to be achieved” “Trade-off analysis documents specifying pros and cons of the environments identified during the previous activity and their suitability with applications from business and technology perspectives” “Artefacts: A set of requirements is produced as a result of this activity” “Artefacts: High-level design documents of potential architecture solution” “Componentisation of architecture to make possible the multiplication of a number of instances of the same component if taking advantage of IaaS technologies” “Predicting the performance of applications and QoS in the cloud […]Performance of the application depends on how effective virtual resources are managed by a cloud provider and testing should be performed on regular basis […]Thus the user needs to test the solution with these considerations and also monitor the cloud performance […]Testing the performance, loadbalancing and security of the migrated solution is a concern since the results depend on the Internet bandwidth, load-balancing and security mechanisms of the cloud service provider” “Verify scalability of the system using various load balancers and algorithms for scaling purpose”

4.1.3 Step 3—Creating Overarching Constructs This step aimed to group fine granular constructs extracted from Step 2 to derive a set of overarching constructs. The grouping of constructs was a gradual process and conducted in two iterations as described in the following. Iteration 1. The first iteration focused on analysing and grouping all constructs identified from the previous step in order to create abstract and overarching constructs (a bottom-up process). Grouping was undertaken on the basis of the key concerns Understanding Organisational Context (C1), Understanding Cloud Migration Objective and Requirements (C2), Proper Cloud Migration Planning (C3), Understanding Legacy Application (C4), Target Cloud Platform and Cloud Service Selection (C5), ReArchitecting Legacy Application (C6), Environment Configuration (C7), Testing (C8) (Section 2.2). As an example to demonstrate the inner working of this iteration,

96


Table 4-3 shows an excerpt of construct definitions (whole definitions are in Appendix C). With respect to the definitions in this table, one can conclude that the common theme among all of these constructs is the notion of proper cloud platform/service selection. In other words, when these constructs are collectively viewed, they are all commonly relate to cloud platform selection, each covering a different aspect of it. Hence, a new overarching construct was defined and labelled as Choose Cloud Provider. This step resulted in nineteen overarching task constructs as follow: (1) Analyse Context, (2) Analyse Migration Requirements, (3) Recover Legacy Application Knowledge, (4) Plan Migration, (5) Design Cloud Solution, (6) Handle Transient Faults, (7) Choose Cloud Provider, (8) Identify Incompatibilities, (9) Resolve Incompatibilities, (10) Enable Multi-Tenancy, (11) Enable Application Elasticity, (12) Make Application Stateless, (13) Decouple Application Components, (14) Communicate Asynchronous, (15) Replicate Application Components, (16) Synchronise Application Components, (17) Test Application, (18) Re-Configure Network, and (19) Deploy Application Components. The full output of this iteration is presented in Appendix D.1. In addition, it was found that 27 out of all identified constructs were a kind of WorkProduct. An example of such artefact is architecture models of existing legacy applications. Such models represent legacy functionalities, different types of dependencies to other applications, interaction points and message flows among legacy components, and the quality of code blocks for reuse and adaptation. Furthermore, some of the constructs were deemed to be general principles for a cloud solution design rather than being discrete Task or Work-Product constructs. The identified Design Principles constructs were Decouple Application Components, Handle Transient

Fault,

Make

Application

Stateless,

Communicate

A-synchronised,

Synchronise Components, Replicate Components, and Make Application Stateless.

97

Chapter 4. Development of the MLSAC Framework Table ‎4-3 An example of an overarching construct, named Choose Cloud Provider

Construct Choosing a Cloud Provider Decision on Cloud Providers

Source ID [S23] [S27]

Platform Selection

[S63]

Select

[S4]

Select

[S67]

Select Cloud Data Store or Data Service

[S11]

Select Target Platform

[S32]

Selected Cloud Environments

[S9]

Selection

[S14]

Selection

[S60]

Selection Selection and Evaluation

[S61] [S44]

Definition from the Source Paper “Choose a proper cloud provider” “Once the requirements are elicited and prioritised, an important activity is to consider the cloud (PaaS) provider” “Choose a suitable cloud provider as well as service model that fulfils the SME Cloud Requirements” “This step will select the best supplier based on value, sustainability, and quality” “Engage and select one or more Cloud supplier and negotiate the deal” “The concrete target data store or data service for the migration is selected in step three by mapping the properties of the Cloud Data Hosting Solution specified in the previous step to the set of available data stores and data services that have been categorised according to the same non-functional and functional properties” “Selecting appropriate technology for the modernised system and technology that can run alongside and communicate with the legacy system” “Trade-off analysis documents specifying pros and cons of the environments identified during the previous activity and their suitability with applications from business and technology perspectives” “Selection of an appropriate CEM-compatible cloud profile candidate” “Selection of an appropriate cloud profile candidate” Nil (No definition was provided) “Based on this cost metrics (response time, labour cost, licensing cost, or energy efficiency) the alternatives can be evaluated and selected”

Iteration 2. The second iteration focused on the restructuring and refining the overarching constructs produced during the first iteration. Particular attention was given to tuning the granularity of the constructs from iteration 1. From modelling perspective, the granularity refers to the aggregation level, or size of information that an entity or construct encapsulates in a model (Henderson-Sellers and Gonzalez-Perez, 2010) and defines a proper size of the resulting entities/constructs across a metamodel or conceptual model. Through a careful review, it was found that some overarching constructs from the previous iteration suffer from indistinguishability and are missing important information due to being coarse-grained. The reader is reminded that the target metamodel was intended to be adequately versatile, cohesive, and to include

98


distinct constructs with minimum overlapping in their definitions. In this regard, the following overarching constructs were recognised as coarse-grained and in need of decomposition into finer granular constructs: Analyse Context, Analyse Migration Requirements, Encrypt Entities, Resolve Incompatibilities, Enable Multi-Tenancy, and Test Application. Such decompositions were represented using a specialisation relationship as described in Step 6. Refining these constructs was deeply inspired by the knowledge sources and the extant cloud migration literature. Some examples illustrate the inner working of this iteration. According to [S35] and [S65], a challenge in the reengineering of a single-tenant application into a multi-tenant application is to ensure tenant isolation. A multi-tenant application should include components for security, performance, customisability, and availability isolation. Therefore, the overarching construct Enable Multi-Tenancy which comprises 36 fine-granular constructs (0Appendix D) could be split into four sufficiently abstract constructs Isolate Tenant Data, Isolate Tenant Performance, Isolate Tenants Availability, and Enable Application Customisation. Another example shows the restructuring of the construct Test Application. Testing in the cloud emphasises non-functional requirements of a migrated application in the cloud. This includes tests for availability, authorised access to data, performance, integrity and interoperability with different cloud platforms, transient faults, and multitenancy (Gao et al., 2011, Chan et al., 2009). In order to capture various tests that may be required in the cloud migration process, the construct Test Application was decomposed into seven constructs namely Test Designed Architecture, Test Application, Test Performance, Test Interoperability, Test Multi-Tenancy, Test Scalability, and Test Security. To sum up, Step 3 shortened the list of all the identified constructs from Step 2 to 72 common constructs, including 65 tasks and 7 work-products, along with variant definitions to be reconciled as discussed in the next step. 4.1.4 Step 4—Harmonising Constructs’ Definitions People in the cloud computing community may have different IT experience and backgrounds and may use different terminologies and phrases to define identical

99


concepts. For example, in Table 4-3, there is a link between different definitions for the construct Choose Cloud Provider. In this table, the definitions are similar in meaning and context, but they have been expressed using different terms. Step 4 was necessary to reconcile various definitions of all constructs created in the previous step. The definitions of constructs (Appendix C) were used during this step. Recommendations from the metamodeling literature (Table 2-5) were also applied to provide a hybrid definition for each construct. The following delineates some illustrative examples in performing this step. As an example, in Table 4-3 the construct Choose Cloud Provider is defined in three studies: (i) Conway et al. in [S4] define it as “This step will select the best supplier based on value, sustainability, and quality”; (ii) Chauhan et al. in [S9] define it as “Identify a set of potential cloud computing platforms based on a project’s nature, data confidentiality and sensitivity requirements, budget constraints and long-term organisational objectives”; and (iii) Huru in [S32] denotes it as “Selecting appropriate technology for the modernised system and technology that can run alongside and communicate with the legacy system”. Conway’s definition [S4] emphasises the nonfunctional qualities of a cloud platform whereas Chanhan’s definition [S9] emphasises aspects of project constraints. On the other hand, Huru’s definition takes into account the interoperability of legacy assets with the cloud services. Thus, a harmonised definition to represent the construct Choose Cloud Platform the author suggests, by the author of this research, was: “Define a set of suitability criteria that characterise desirable features of cloud platforms. The criteria include provider profile (pricing model, constraints, offered QoS, electricity costs, power, and cooling costs), organisation migration characteristics (migration goals, available budget), and application requirements. Based on the criteria identify and select suitable cloud providers”. Figure 4-2 demonstrates this harmonisation process.

100


Figure ‎4-2 Harmonizing the constructs

A second example is the construct Recover Legacy Application Knowledge which has several definitions in existing migration solutions. Rajaraajeswari et al. [66] define it as “Measure and collect real usage data of an application before it is migrated”. In addition, Zhang et al. [S13] defines a construct Recover Legacy Application Knowledge to mean “Analyse the legacy system and reconstruct an architectural model of the legacy application”. Furthermore, Laszewski’s method [S25] defines it as “Analyse the dependencies between an application’s various components and the database, as well as the complexity of the migration effort”. These three definitions are similar in their meaning and context but have different emphases. Rajaraajeswari’s definition is specific to measure the performance of a legacy application prior to the migration. Zhang’s definition focuses on recovering a representational model of a legacy application. Laszewski’s definition is related to the dependency among legacy application components and necessary effort to make them cloud-enabled. Thus, a suggested synthesised definition for the construct Recover Legacy Application Knowledge is “Recapture the abstract representation of application architecture in terms of functionalities, data, constraints, structure of parts/components, business and data layers, design quality, complexity, and coupling”. The full set of constructs and definitions after reconciliation is presented in Table 4-9 to Table 4-12.

101


4.1.5 Step 5—Organising Constructs into Phases To create a coherent metamodel and reduce the complexity of the cloud migration process, all the reconciled constructs from the previous step were organised into migration phases. To this aim, the knowledge source was scrutinised to identify generic phases of the cloud migration process. For example, Conway et al (denoted by [S4]) include four phases namely Architect, Engage, Operate, and Refresh. Strauch et al. (denoted by [S10]) define three phases as Assessment, Analysis and Design, and Migration, Deployment, and Support. Similarly, Jamshidi’s model (denoted by [S68]) includes three phases including Migration Planning, Migration Execution, and Migration Evaluation. By applying the criteria in Section 4.1.2 and synthesising the similarity of phases in [S4], [S10], and [S68], this research defines three phases including Plan, Design, and Enable as follows. In the Plan Phase, initial migration tasks are performed such as understanding the organisational context and legacy applications. The Design Phase is to define a suitable high-level cloud-based architecture for a legacy application. In Enable Phase, migration tasks such as incompatibility resolutions and network configuration are carried out. With respect to the phases’ definitions and suggestions in the knowledge source prepared in Step 1, those constructs with common themes in a particular phase were placed into that phase. Organising the constructs into phases was a bottom-up process. For example, according to [S12] and [S65], the constructs Design Cloud Solution, Cloud

Solution

Architecture,

Apply

Design

Principles,

Choose

Cloud

Platform/Provider, and Virtual Machine Specifications are the essential constructs for the Design Phase. Table 4-4 presents the result of organising the constructs in the phases. Table ‎4-4 Constructs reconciled in Step 4 were organised into the metamodel phases

Phase Plan Design Enable

Construct Analyse Migration Requirements, Migration Requirements, Migration Plan, Plan Migration, Analyse Context, Recover Legacy Application Knowledge, Application Architecture Choose Cloud Provider, Identify Incompatibilities, Design Cloud Solution, Apply Design Principles, Virtual Machine Specifications Test Application, Enable Elasticity, Rebalance Application, Isolate Tenants, Encrypt/Decrypt Entities, Resolve Incompatibilities

102


4.1.6 Step 6—Defining Relationships among Constructs In this step relationships among the constructs were specified. These relationships help to understand how the constructs are related during the migration process. The UML notations

were used to represent Association, Specialisation and

Aggregation relationships, respectively (UML, 2004). The relationships were identified on the basis of the knowledge source and the output from Step 5. The output of this step is presented in Appendix E. The following examples illustrate the way of defining relationships among the constructs. The Uses Association relation, symbolised with

, shows that a construct uses data or

artefacts provided by another construct. As an example, the relationship between constructs Analyse Migration Requirements and Choose Cloud Provider means that project requirements (e.g. goals and budget constraints) are used to identify and assess a list of candidate cloud platforms. Such a relationship has been stated in Chauhan’s method (denoted by [S9]): “Identify a set of potential cloud computing platforms based on a project’s nature, data confidentiality and sensitivity requirements, budget constraints and long-term organisational objectives” As another example, the Association between constructs Design Cloud Solution and Plan Migration indicates that a blueprint for the distribution and deployment of application components in the cloud is defined based on the output from a migration plan. In Strauch’s method language (denoted by [S10]), this relationship is defined as: “Based on the selection of the migration scenario, a migration strategy is formulated by considering properties such as live or non-live migration, complete or partial migration, and permanent or temporary migration to the Cloud” The second type of relationship, Follows Association, was used for defining the sequence of the migration process execution. For example, as shown in Figure 4-3, the relation between the constructs Identify Incompatibilities and Choose Cloud Platform signifies that once a particular platform is chosen, incompatibility issues between legacy application components and cloud services may be triggered. The evidence is that: “An application is analysed to assess its compatibility with the potential cloud computing environments. For example, it may be the case that a target PaaS cloud does not support frameworks or specific technologies being used by an

103


application. If such issues are identified, then these need to be resolved first” Chauhan’s method (denoted by [S9])

Figure ‎4-3 Follow Association relationship between Identify Incompatibilities and Choose Cloud Provider

The third type of relationship, Produces Association, means that a construct is the outcome of performing another construct. For instance, the work-product Cloud Solution Architecture is the output of the task Design Cloud Solution. This relationship is captured by Chauhan’s method (denoted by [S9]): “This activity [Identification of Potential Architecture Solutions] results in highlevel design documents of potential architecture solution” The forth kind of the relationship, isAGroupOf Association, denoted by

, was used

to show an aggregation relationship among constructs phases. For instance, Recover Legacy Application Knowledge belongs to the Plan Phase with an aggregation relationship as discussed in Step 2.3. And finally, the Specialisation relationship, denoted by

, indicates that a

construct is a specific kind (or child) of a super construct. Including this kind of relationship in the metamodel is a direct result of Step 3 where coarse-grained overarching constructs were decomposed into finer constructs. An example is the constructs Refactor Codes, Develop Integrators, and Migrate Data which are used to resolve incompatibilities between applications and chosen cloud platform as mentioned in [S6], [S10], [S11], [S26], [S27], [S31], [S46], and [S65]. These constructs are particular kinds of adaptation and considered as a child for the construct Resolve Incompatibilities. Table 4.5 shows an excerpt of relationships among the constructs.

104


The full output of this step is presented in Appendix E. Table ‎4-5 Relationships among the constructs in the metamodel

1)

Relationship Type Association

Relationship Name Uses

2)

Association

Uses

3)

Association

Produces

4)

Association

Follows

5)

Aggregation

isAGroupOf

6)

Specialisation

isAKindOf

7)

Specialisation

isAKindOf

8)

Specialisation

isAKindOf

4.1.7 Step

7—Defining

Construct 1 Name Type Choose Cloud Task Provider Design Cloud Solution Design Cloud Solution Choose Cloud Provider Recover Legacy Application Knowledge Re-factor codes Develop Integrators Migrate Data

Task Task Task Task

Task Task Task

Relationships

Construct 2 Name Type Analyse Task Migration Requirements Plan Migration Task

[S9]

Cloud Solution Architecture Identify Incompatibilities Plan

WorkProduct Task

[S6], [S9], [S65]

Phase

Step 2.3

Resolve Incompatibilities Resolve Incompatibilities Resolve Incompatibilities

Task

Step 2.1 (Iteration 2) Step 2.1 (Iteration 2) Step 2.1 (Iteration 2)

Between

Task Task

Migration

Source

[S10], [S29], [S24] [S9],[S12],[S65]

Types

and

Metamodel Constructs It is important to realise that the migration types (Section 2.1.3) may raise different concerns that need to be addressed during the migration process. Indicating a connection between a chosen migration type and the metamodel constructs helps users in a better understanding the use of the metamodel in a migration scenario. Table 4-13 is a guideline to show all situations in which a construct should be incorporated into the migration process with respect to a given migration type. Symbols √, (√), and × specify a Mandatory, Situational, and Unnecessary adoption of a construct, respectively. As shown in Table 4-13, some constructs are deemed as a constant element of any migration type. For example, as confirmed in [S5], [S7], and [S68], it is quite common to understand the impact of organisational changes, risks, and effects associated with cloud adoption before a migration process proceeds. Therefore, the construct Analyse Organisational Changes occurs in all migration types I, II, III, IV, and V. As another example, moving legacy components from a local organisation network to the cloud requires a new architecture model, which defines a topology of migrated components on the cloud and their communication with none-migrated components. Hence, Design

105


Cloud Solution is a mandatory construct in all the migration types. In general, with respect to the knowledge source (Table 2-3), the following constructs were found common in all the migration types: Analyse Business Requirements, Analyse Migration Cost, Analyse Migration Feasibility, Analyse Network Change, Analyse Organisational Changes, Analyse Stakeholders Change, Analyse Technical Requirements, Choose Cloud Provider, Cloud Solution Architecture Model, Define Plan, Deploy Application Components, Handle Transient Fault, Legacy Application Architecture, Migration Plan, Migration Requirements, Synchronise Application Components, Test Network Connectivity, and Test Security. The adoption of some constructs, mainly relevant to the concerns Re-Architecting Legacy Application (C6) and Environment Configuration (C7), and Testing (C8) (Section 2.2) largely depends on a choice of migration type, cloud platform, cloud architecture design, and cross-cutting concerns such as security, elasticity, performance variability, network latency, and availability. This situation is specified in Table 4-13 with the symbol (√). For example, deploying some legacy components in the cloud or replacing them with cloud services may require applying a series of adaptations and design principles on both migrated and none-migrated components depending on a chosen cloud platform. For example, as mentioned earlier in Section 2.2.6, migrating the legacy data layer to a cloud database solution may require some adaptations on legacy components that depend on different aspects such as the supported functionalities of the chosen cloud database solution [S10], [S11], [S60], [S65], and [S68]. Enabling multi-tenancy, as captured in the metamodel construct Isolate Tenants, is to guarantee the security, performance, availability, and customisation isolation of tenants running on the same server. The multi-tenancy should be taken into account in the migration type II. However, it is not concerned with other migration types. For example, in the migration type V, in which an application is encapsulated into a virtual machine and deployed on a cloud server, tenant isolation is handled by the server. Taking into account the definitions of migration types III and IV, neither necessitates using the constructs Isolate Tenants and Test Multi-Tenancy, Enable Elasticity,

106


Obfuscate Codes, Rebalance Application, Test Scalability, and Virtual Model Specification in the migration process. However, for migration type IV and depending on the choice of a cloud platform, moving from a legacy data layer to a cloud database solution may raise incompatibility issues because of differences between data types, functionalities, and query definitions defined by the legacy data layer and their equivalents offered by the chosen cloud database solution. As such, developers may need to identify and resolve incompatibilities and perform modifications to the legacy business and data layers to utilise the cloud services. These issues rarely or never occur if migration type III is intended. 4.1.8 Step 8—Cross-checking of the metamodel against existing methods To show that the metamodel provides sufficient coverage of important and relevant cloud migration constructs, the ten methods reviewed in Section 2.3 were used as a benchmark. The constructs in these methods were mapped to the proposed conceptual model to highlight the missing constructs in the proposed process model. These selected methods provide a wide span of legacy system migration to the cloud. Table ‎4-6 Coverage of constructs in the cloud migration methods by the metamodel

Method

Legacy-toCloud Migration Horseshoe [S27]

Cloud-RMM [S68]

Corresponding the constructs in the metamodel

Method’s construct Feasibility Study Requirement Analysis Decision on Cloud Providers Migration Strategy Development Legacy Architecture Description Architecture Change Implementation Code Consistency Conformance Migration Planning Cloud-Service Architecture Feasibility Study Requirement Analysis Decision on Provider Sub-System to be Migrated Migration Strategies Development Code Modification Architecture Recovery Data Extraction Architecture Adaptation Test Deployment

107

Analysis Context Analyse Migration Requirements Choose Service Cloud Provider Define Plan Recover Legacy System Knowledge Resolve Incompatibilities Recover Legacy System Knowledge Define Plan Design Cloud Solution Analyse Context Analyse Migration Requirements Choose Service Cloud Provider Design Cloud Solution Define Plan Refactor Legacy Codes Recover Legacy System Knowledge Adapt Data Resolve Incompatibilities Test System Deploy System Components


Chauhan [S9]

Effort Estimation Organization Change Distribution Multi-Tenancy Elasticity Analysis Requirements Identification Identification of Potential Cloud Hosting Environments Identification of Potential Architecture Solutions Evaluation of Cloud Environments for Cloud Specific Quality Attributes Analysing Application Compatibility With Potential Cloud Environments Evaluation of Proposed Solutions and Effected Components Against Target Platforms Implementation and Refactoring System Requirements Finalised Design Decision and Modified System Architecture Selected Cloud Environments Trade off Analysis of Cloud Environment Trade off Analysis of Quality Attributes Cloud

Analyse Migration Cost Analyse Organisational Changes Define Parts Distribution in Cloud Isolate Tenant Enable Elasticity Analyse Migration Requirements Choose Cloud Service/Platform Design Cloud Solution Design Cloud Solution Identify Incompatibilities Design Cloud Solution

Refactor Legacy Code Analyse Migration Requirements Design Cloud Solution, Apply Design Principles Choose Cloud Service/Platform Choose Cloud Service/Platform Choose Cloud Service/Platform

Table ‎4-7 Coverage of constructs in the cloud migration methods by the metamodel (continue)

Deploy System Components, Configure Network Refactor Legacy Code Adapt Data Test System

Installation and Configuration Tran [S6]

Zhang [S13]

Oracle [S25]

Code Modification Migration Testing Architectural Representation of the Legacy System Redesign the Architecture Model Web Service Generation Web Service-Based Invocation of legacy Functionalities Selection of Suitable Cloud Computing Platform Web Service Deployment in the Service Cloud

Recover Legacy System Knowledge

Assessment Migration Service Provider Migration Effort Estimate IT Resource Requirement for the Migration Project Capture Exhaustive Amounts of Information from the Source Systems Database Schema Layout

Test System Choose Cloud Service Platform Migration Cost, Identify Incompatibilities Analyse Technical Requirements

108

Design Cloud Solution Develop Integrators/Wrappers Develop Integrators/Wrappers Choose Cloud Service Platform Deploy System Components


Adapt Data


ARTIST [S64]

Amazon [S71]

REMICS [S3]

Testing Optimisation Deployment

Test System Enable Elasticity Deploy System

Technical Feasibility Analysis Business Feasibility Analysis Application Discovery and Understanding Target Environment Specification Detect Inconsistencies Cloud Assessment Understand Various Storage Options Application Migration Leverage the Cloud Optimisation Establishing the Context Modernising the Software Architecture Modernising Data Managing Non-Functional and QoS Requirements in the Cloud Verification and Validation in the Cloud Verifying the Scalability of Applications

Recover Legacy System Knowledge Analyse Migration Feasibility Recover Legacy System Knowledge Choose Cloud Service Platform Identify Incompatibilities Analyse Migration Feasibility Choose Cloud Service Platform Design Cloud Solution Enable Elasticity Enable Elasticity Analyse Migration Feasibility Decouple Legacy System Components Adapt Data Analyse Technical Requirements Test Performance Test Scalability

Table ‎4-8 Coverage of constructs in the cloud migration methods by the metamodel (continue)

Strauch [S11]

Select Migration Scenario Describe Desired Cloud Data Hosting Solution Select Cloud Data Store or Data Service Identify Patterns to Solve Potential Migration Conflicts

Define Plan Choose Cloud Service Platform Choose Cloud Service Platform Identify Incompatibilities

Refactor Application Architecture Refactor Legacy Codes Migrate Data Adapt Data The full definition of the methods’ constructs is presented in Appendix C.

The tables show the mapping of constructs in these methods against those in the process model. The results indicate that the process model covers all constructs defined in the ten migration methods. For example, in the Legacy-to-Cloud Migration Horseshoe [S27], there is a construct named Decision on Cloud Providers. The proposed conceptual model represents this construct by the construct Cloud Provider Selection. Similarly, the construct Migration Planning is mapped to the construct Define Plan in the process model. The Cloud-RMM is another example. This method defines the construct Requirement Analysis that corresponds to the construct Analyse Migration Requirements in the process model. It is worth mentioning that the process model not

109


only covers existing methods, but also provides support for constructs not addressed by existing methods.

110

Chapter 4. Development of the MLSAC Framework Table ‎4-6 Coverage of constructs in the cloud migration methods by the metamodel

Method

Legacy-toCloud Migration Horseshoe [S27]

Cloud-RMM [S68]

Chauhan [S9]

Corresponding the constructs in the metamodel

Method’s construct Feasibility Study Requirement Analysis Decision on Cloud Providers Migration Strategy Development Legacy Architecture Description Architecture Change Implementation Code Consistency Conformance Migration Planning Cloud-Service Architecture Feasibility Study Requirement Analysis Decision on Provider Sub-System to be Migrated Migration Strategies Development Code Modification Architecture Recovery Data Extraction Architecture Adaptation Test Deployment

Analysis Context Analyse Migration Requirements Choose Service Cloud Provider Define Plan Recover Legacy System Knowledge Resolve Incompatibilities Recover Legacy System Knowledge Define Plan Design Cloud Solution Analyse Context Analyse Migration Requirements Choose Service Cloud Provider Design Cloud Solution Define Plan Refactor Legacy Codes Recover Legacy System Knowledge Adapt Data Resolve Incompatibilities Test System Deploy System Components

Effort Estimation Organization Change Distribution Multi-Tenancy Elasticity Analysis Requirements Identification Identification of Potential Cloud Hosting Environments Identification of Potential Architecture Solutions Evaluation of Cloud Environments for Cloud Specific Quality Attributes Analysing Application Compatibility With Potential Cloud Environments Evaluation of Proposed Solutions and Effected Components Against Target Platforms Implementation and Refactoring System Requirements Finalised Design Decision and Modified System Architecture Selected Cloud Environments Trade off Analysis of Cloud Environment Trade off Analysis of Quality Attributes Cloud

Analyse Migration Cost Analyse Organisational Changes Define Parts Distribution in Cloud Isolate Tenant Enable Elasticity Analyse Migration Requirements Choose Cloud Service/Platform

111

Design Cloud Solution Design Cloud Solution Identify Incompatibilities Design Cloud Solution

Refactor Legacy Code Analyse Migration Requirements Design Cloud Solution, Apply Design Principles Choose Cloud Service/Platform Choose Cloud Service/Platform Choose Cloud Service/Platform

Chapter 4. Development of the MLSAC Framework Table ‎4-7 Coverage of constructs in the cloud migration methods by the metamodel (continue)

Deploy System Components, Configure Network Refactor Legacy Code Adapt Data Test System

Installation and Configuration Tran [S6]

Zhang [S13]

Oracle [S25]

ARTIST [S64]

Amazon [S71]

REMICS [S3]

Code Modification Migration Testing Architectural Representation of the Legacy System Redesign the Architecture Model Web Service Generation Web Service-Based Invocation of legacy Functionalities Selection of Suitable Cloud Computing Platform Web Service Deployment in the Service Cloud


Assessment Migration Service Provider Migration Effort Estimate IT Resource Requirement for the Migration Project Capture Exhaustive Amounts of Information from the Source Systems Database Schema Layout Testing Optimisation Deployment

Test System Choose Cloud Service Platform Migration Cost, Identify Incompatibilities Analyse Technical Requirements

Technical Feasibility Analysis Business Feasibility Analysis Application Discovery and Understanding Target Environment Specification Detect Inconsistencies Cloud Assessment Understand Various Storage Options Application Migration Leverage the Cloud Optimisation Establishing the Context Modernising the Software Architecture Modernising Data Managing Non-Functional and QoS Requirements in the Cloud Verification and Validation in the Cloud Verifying the Scalability of Applications

Recover Legacy System Knowledge Analyse Migration Feasibility Recover Legacy System Knowledge

112

Design Cloud Solution Develop Integrators/Wrappers Develop Integrators/Wrappers Choose Cloud Service Platform Deploy System Components


Adapt Data Test System Enable Elasticity Deploy System

Choose Cloud Service Platform Identify Incompatibilities Analyse Migration Feasibility Choose Cloud Service Platform Design Cloud Solution Enable Elasticity Enable Elasticity Analyse Migration Feasibility Decouple Legacy System Components Adapt Data Analyse Technical Requirements Test Performance Test Scalability

Chapter 4. Development of the MLSAC Framework Table ‎4-8 Coverage of constructs in the cloud migration methods by the metamodel (continue)

Strauch [S11]

Select Migration Scenario Describe Desired Cloud Data Hosting Solution Select Cloud Data Store or Data Service Identify Patterns to Solve Potential Migration Conflicts

Define Plan Choose Cloud Service Platform Choose Cloud Service Platform Identify Incompatibilities

Refactor Application Architecture Refactor Legacy Codes Migrate Data Adapt Data The full definition of the methods’ constructs is presented in Appendix C.

4.2

Resultant MLSAC Metamodel Version 1.0

Steps 1 to 8 resulted in a generic process model of legacy application migration to cloud environments. It does not narrow to technical and platform specific details required by situation-specific cloud migration scenarios; instead, it presents an abstract view of what each transition process may entail. Such details are deferred to each individual instantiations of the metamodel where users can apply various techniques in order to perform tasks. To represent the metamodel in a clear and well-structured manner, a simple UML notation (UML, 2004), has been used which is a semi-formal and de-facto for information modelling. In this regard, UML notation Class represents metamodel constructs. While metamodel constructs have specific meanings that are suitable for the cloud migration domain, stereotypes have been used to extend the meaning of UML class. A stereotype is a mechanism for extending UML notations. In this research, the notation Class has been extended for the purpose of the metamodel. On that basis, the stereotypes , , , and > represent phase, task, work-product, and principles constructs, respectively. Figure 4-4 to Figure 4-6 and Table 4-9 to Table 4-12 present the metamodel in the form of phases, tasks, work-products, and design principles along with their objectives. In the following tables, the term application component refers to both business logic and data components.

113


4.2.1 Plan Phase Table 4-9 and Figure 4-4 present Plan Phase of the metamodel. Table ‎4-9 Tasks and their definitions in Plan Phase

Task

Analyse Business Requirements

Analyse Cost

Migration

Analyse Migration Feasibility

Analyse Change

Network

Analyse Organisational Changes Analyse Stakeholders Change

Analyse Technical Requirements

Define Plan

Recover

Legacy

Definition Provide an understanding of what an organisation wants to achieve and goals and expectations are to be met by cloud migration.

Analyse migration to cloud with respect to the cost of application modification, installation, training, administration, license management, developing cloud skills, pricing models of the service providers, and infrastructure procurement imposed by the migration. Identify potential organisational constraints regarding the adoption of a particular cloud model, based on information available in the organisation profile and then perform a feasibility study to evaluate the benefits and the consequences of migrating to the cloud. Perform an impact analysis of potential changes in organisation network due to migration in order to identify any side effect on communication between local and cloud components and the required bandwidth. Analyse the impact of cloud migration on the structure and resources of organisation.

Goals Project management, Quality assurance, Traceability to migration requirements Cost estimation, Risk mitigation

Risk mitigation

Risk mitigation

Risk mitigation

Analyse the impact of cloud migration on stakeholders, their responsibilities, and working practices.

Risk mitigation

Acquire a set of legacy requirements such as computational requirements, servers, data storage and security, networking and response time, and elasticity requirements from multiple stakeholders about the target application according to the current configuration setting of the legacy application. This helps to gain a good understanding of different kinds of architectural changes that needed to be made in the legacy application. Define a correct and safe sequence of tasks that guide the migration process by analysis feedback from stakeholders. A plan may a procedure for (i) notifying legacy application users about the cloud migration and temporal unavailability of applications during the migration period and activating them after the migration, (ii) rollback to an in-house version of the legacy in the case of occurrence of any significant risk during the migration process, (iii) retiring legacy components and infrastructure that are no longer needed, after a predefined period of monitoring and successful migration from original environment to the cloud. Produce a complete representation of legacy architecture

Project management, Quality assurance, Traceability to migration requirements

114

Project Management, Risk mitigation

Understanding


Application Knowledge

application including its data, components, dependencies among components and infrastructure, application data usage and resource utilisation model (e.g. CPU, Network, storage).

of the legacy application dependencies

Figure ‎4-4 Plan Phase

4.2.2 Design Phase Table 4-10 and Figure 4-5 present Design Phase of the metamodel. Table ‎4-10 Tasks and their definitions in Design Phase

Task

Definition

Goals

Define a set of suitability criteria that characterise desirable features of cloud providers. The criteria include provider profile (e.g. pricing model, constraints, offered QoS, electricity costs, power, and cooling costs), organisation migration characteristics (e.g. migration goals and available budget), and application requirements. Based on the criteria, identify and select suitable cloud providers.

Finding a best possible providers that address the migration requirements

Design Cloud Solution

Identify legacy components which are appropriate for the migration to the cloud regarding identified requirements (e.g. workload, data privacy, confidentiality, latency, dependencies between application components, and migration goals) and then define their deployment and distribution in the cloud environment on the basis of organisation profile, cost saving, expected workload, performance, transaction delay, availability, security, and constraints.

Finding an optimum set of legacy parts for the cloud migration and their distribution in the cloud.

Identify Incompatibilities

Identify and assess the list of potential incompatibilities between existing application

An estimation of cost and effort to

Choose Cloud Platform/Provider

115


Make Application Stateless

components and selected cloud service. Different sources of incompatibilities should be checked including library, database, interface, behavioural, code style, communication protocol, offered QoS, and policy mismatches.

resolve incompatibilities

Provide support in the application to the handle safety and traceability of tenant’s session when various application instances are hosted in the cloud.

Facilitating scalability, Increasing maintainability, Increasing transparency

Decouple Application Components

Decouple the application components from each other. Use mediator and synchronisation mechanisms to manage interaction between the loosely coupled components in the cloud environment.

Facilitating scalability, Increasing maintainability, Increasing transparency

Replicate Application Components

Partition and deploy the application components (e.g. database, business logic) on multiple cloud servers.

Figure ‎4-5 Design Phase

4.2.3 Enable Phase Table 4-11 and Figure 4-6 present Enable Phase of the metamodel.

116

Increasing availability

Chapter 4. Development of the MLSAC Framework Table ‎4-11 Tasks and their definitions in Enable Phase Task

Adapt Data

Develop Integrators

Deploy Application Components

Enable Elasticity

Encrypt/Decrypt Database Handle Transient Faults Isolate Tenant Availability

Isolate Tenant Customisability

Isolate Tenant Data Isolate Tenant Performance Encrypt/Decrypt Messages

Obfuscate Codes

Rebalance Application

Definition Refine the current database schema for making it compliant with the schema of cloud database solution. Enhance the data access layer by adaptors and convertors so as to fulfil functionalities and necessary optimised query transformations which are not supported by a chosen cloud database solution. Also, convert database data type to the target cloud database solution. Develop a mediator component that resolves mismatches between legacy and cloud services that are plugged to the legacy. This component wraps/transforms incompatibility (e.g. message format, interaction protocols) between the legacy and cloud services.

Install application components and any required third party tools in the cloud.

Goals Increasing interoperability, Increasing reusability

Increasing interoperability, Reducing vendor lock-in, Increasing transparency access to the application parts in cloud -

Define scaling rules and provide support for dynamic acquisition and release of cloud resources.

Increasing resource efficiency

Encrypt critical database prior hosting in the cloud.

Increasing security

Detect and handle transient faults may occur in the cloud.

Handling accidental faults Reducing fault resiliency, Increasing availability Increasing customisability

Detect and handle faults that may incur in a tenant in a way that it cannot be propagated to other tenants.

Analyse commonality and variability in the target domain and provide support for the customisation of application components on the basis of particular needs and situations of tenants before and during running application in the cloud. Protect tenants' data from to be accessed by other tenants. Each tenant should be authorised and able to access to its own data. Protect tenant’s performance from being affected by other tenant’s behaviour. Use an encryption mechanism to secure messages transmission between the local legacy components and those hosted on cloud servers. Protect unauthorised access to code blocks of components by other tenants that are running on the same cloud provider. Use encryption mechanisms in the sense that no other tenants will be able to access, read, or alter the code blocks with the components when running in the cloud. Define support for moving application components from in lower-preferred clouds and launching replacement

117

Increasing security Keeping tenant performance Increasing security Increasing security

Satisfying application owner


Refactor Codes

Re-configure Network Synchronise Application Components Test Interoperability

Test Multi-tenancy

instances in higher-preferred clouds to satisfy user preferences.

preference

Refine (or re-implement) the source code for being compatible and able to interact with the selected cloud platform programming language. Also, refine (or reimplement) component interface operations, signature, messages, and data type for being able to interact with the selected cloud platform. Re-configure the running environment of the application including reachability policies to resources and network, connection to storages, setting ports and firewalls, and load balancer. Provide a support in the application to synchronise multiple components (e.g. database replica) hosted legacy network and cloud servers.

Reusing existing codes, reducing development time, resolving incompatibilities

Test the compatibility of components with different cloud environments specifically, when components are supposed to switch between different cloud platforms. Test if tenants can easily configure the application components, i.e. user interfaces, business logic and workflows, and functional services. Test the network connectivity between local components and components in the cloud.

Test Network Connectivity

Test Performance Test Scalability Test Security

Test the performance (e.g. process speed, response time, throughput, latency, and etc.) of the application when subjected to increased load from multiple tenants. Test to assure the application acquire and release the computing resources in an efficient manner. Test application components and reachability policies to access these components against the security requirements.

118

Increasing security

Guarantee consistency of application components Detecting interoperability issues Detecting multitenancy issues Assuring connectivity between localhosted components and cloud-hosted components Detecting performance bottlenecks Detecting scalability issues Detecting security issues


Figure ‎4-6 Enable Phase

119


4.2.4 Work-Product Table 4-12 presents defined work-products of the MLSAC metamodel. Table ‎4-12 Work-products and their definitions Task Application Templates (Variability Models) Cloud Solution Architecture Legacy Application Model Migration Plan Migration Requirements Virtual Model Specification

Definition A set of models allowing tenants/application users to customise variation points and features in the application components. These allow tenants/users to configure application components. A complete high-level architecture document that will serve in later stages as a guidebook for the implementation A model of legacy application including its components and their deployment relations. A document that defines the execution of the migration process and sequence with which legacy application is to be moved to the cloud. A set of requirements as a result of task Analyse Migration Requirements. Virtual images of the application that are associated with the application components.

4.2.5 Metamodel Guideline Table 4-13 shows the relationships between the metamodel constructs and the migration type indicating situations in which a construct is incorporated into the migration process.

120


Table ‎4-13 Triggering‎of‎constructs‎in‎different‎migration‎types‎√:‎Mandatory,‎(√):‎Situational,‎×‎Unnecessary Construct Adapt Data Analyse Business Requirements Analyse Migration Cost Analyse Migration Feasibility Analyse Network Change Analyse Organisational Changes Analyse Stakeholders Change Analyse Technical Requirements Application Templates Choose Cloud Platform/Provider Cloud Solution Architecture Decouple Application Components Design Cloud Solution Define Plan Deploy Application Components

I × √ √ √ √ √ √ √ × √ √ (√)

Migration Type II III IV (√) (√) (√) √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ (√) × × √ √ √ √ √ √ (√) (√) (√)

V (√) √ √ √ √ √ √ √ × √ √ (√)

√ √ √ (√)

√ √ √ (√)

√ √ √ (√)

√ √ √ (√)

√ √ √ (√)

(√) × (√) √ √ ×

(√) (√) (√) √ √ √

× (√) (√) √ × ×

× (√) (√) √ √ ×

(√) (√) (√) √ √ ×

× × × √ (√)

√ √ √ √ (√)

× × × √ (√)

× × × √ (√)

× × × √ (√)

Develop Integrators Enable Elasticity Encrypt/Decrypt Database Encrypt/Decrypt Message Handle Transient Fault Identify Incompatibilities Isolate Tenant Availability Isolate Tenant Customisability Isolate Tenant Data Isolate Tenant Performance Legacy Application Model Make Application Stateless

Situation The incorporation of this task for the migration types II, III, IV, V depends on the choice of a cloud platform. Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory The incorporation of this task in the migration type II depends on a need for support application customisability. Mandatory Mandatory The incorporation of this design principle into the migration process depends on the definition of architecture model and the distribution of application components in the cloud. Mandatory Mandatory Mandatory The incorporation of this task depends on the choice of a cloud platform and required effort to refactor/modify legacy codes. If the code refactoring, as supported by Refactor Codes, is costly, then developing integrators/adaptors can be served as an alternative solution to hide incompatibilities. The incorporation of this task in the migration types I, II, and V depends on a need for the application elasticity. The incorporation of this task in the migration types depends on the security requirement. The incorporation of this task in the migration types depends on the security requirement. Mandatory Mandatory This is a mandatory task for the migration type II but it is not required to be incorporated in other migration types. This is a mandatory task for the migration type II, if application customisability is required. This is a mandatory task for the migration type II, if data isolation and security is required are required. This is a mandatory task for the migration type II, if performance isolation is required. Mandatory The incorporation of this design principle into the migration process depends on the definition of architecture

121


Migration Plan Migration Requirements Obfuscate Codes Recover Legacy Application Knowledge Rebalance Application Re-configure Network Refactor Codes Replicate Application Components Synchronise Application Components Test Interoperability Test Multi-tenancy Test Network Connectivity Test Performance Test Scalability Test Security Virtual Model Specification

√ √ (√)

√ √ (√)

√ √ ×

√ √ ×

√ √ (√)

√ (√)

√ (√)

√ ×

√ ×

√ (√)

√ (√) (√)

√ (√) (√)

√ (√) (√)

√ (√) (√)

√ (√) (√)

(√) (√) ×

(√) (√) √

(√) × ×

(√) (√) ×

(√) (√) ×

(√)

(√)

(√)

(√)

(√)

(√)

(√)

(√)

(√)

(√)

(√) (√) (√)

(√) (√) (√)

× (√) ×

× (√) ×

(√) (√) (√)

model and the distribution of application components in the cloud. Mandatory Mandatory The incorporation of this task into the migration process for migration types I, II, and V depends on security requirements. Mandatory The incorporation of this task into the migration process for migration types I, II, and V depends on the user preferences (e.g. scalability). Mandatory. The incorporation of this task depends on the choice of a cloud platform. The incorporation of this task depends on the choice of a cloud platform, architecture model, the distribution of application components, and expected availability in the cloud. It depends on the definition of architecture model and the distribution of application components in the cloud. It depends on the choice of cloud platform. The incorporation of this task into the migration type II is required if multi-tenancy is enabled in a legacy application. The incorporation of this task into the migration types depends on a need for the connectivity between migrated and none-migrated components. The incorporation of this task into the migration types depends on a need for application performance in the cloud. The incorporation of this task into the migration types depends on a need for application scalability in the cloud. The incorporation of this task into the migration types depends on a need for application security in the cloud. The incorporation of this task into the migration types depends on a need for virtual machine modelling.

122


4.2.6 Discussion The following discusses some concerns faced during the development of MLSAC metamodel, including bias in publication selection, the granularity of constructs, and the creation process. Bias in publication selection. Although in Step 1 (Section 4.1.1), preparing knowledge source, the search strings were defined to cover as many cloud migration studies as possible, the threat of discarding relevant studies still exists. This is due to the fact that researchers and practitioners in the field use different terminologies to refer to identical things. For example, when applying the snowballing technique (searching for all references contained in the studies), it was noticed different terminologies were used to describe the migration process. As shown in Section 4.1.4, Decision on Cloud Providers and Select Target Platform were used and yet both collectively mean the same thing. Furthermore, in cases where the focuses of studies had not been cloud migration, they may not have been included in the search results whereas they might have been relevant to this study. For example, [S65] is a well-cited source that included very relevant practice and considerations for the legacy to cloud migration, but was not identified using our initial search strings. To reduce the likelihood of missing relevant papers, the initial search strings were broadened (Table A.1 in Appendix A) to cover relevant papers. Additionally, an extensive manual search on scientific databases and conference proceedings was performed and mentioned in Section 4.1.1. In total, one hundred and eighty two primary papers relating to cloud migration were manually studied for inclusion. Nevertheless, due to the large number of publications, it was not possible to guarantee that search strings have resulted in identifying a complete set of relevant studies in a still fuzzy research area like cloud migration. As creation of the knowledge source took place between October 2013 to May 2015, this research may have missed publications after this period. As a final note, SLRs are criticised for being a fixed, mechanical, and rigid protocoldriven process for the study selection process and review which impede critical thinking and scholarly examining of knowledge in a literature review (Boell and Cecez-

123


Kecmanovic, 2015, Hjørland, 2011). The author is aware of these limitations and to alleviate them, the SLR was engaged in an early understanding and critical reading of the cloud migration literature, and fine-tuning search strings, inclusion and exclusion criteria, and conducting the review as understanding of the cloud migration body of knowledge was being developed. In other words, the SLR was itself a process of understanding the cloud migration literature. Granularity of the metamodel constructs. A recurrent challenge in the development of any kind of conceptual model is to determine a suitable level of granularity for constructs. As mentioned in the second iteration of the creation of the conceptual model (Section 4.1.3), granularity refers to the degree of classification, aggregation level, or size of information that a construct encapsulates (Henderson-Sellers and GonzalezPerez, 2010). According to (Smirnov et al., 2012, Henderson-Sellers and GonzalezPerez, 2010), if a model includes too fined-grained elements/constructs, it may indulge in too many details. On the other hand, a too coarse-grained model may be confined by too little information. As a countermeasure, this research leveraged existing proven conceptual models and process models in traditional legacy system reengineering and software engineering literature and key concerns presented in Section 2.2 as a conceptual frame to organise constructs and form the process model. Metamodel creation process. Although the metamodeling (Section 4.1) was based on a rigorous systematic process and relied on the literature (sections 2.5.2.4 and 2.5.2.7), there is a risk of subjective interpretation of knowledge sources during metamodeling since the entire process was undertaken by a single researcher and author. To reduce subjectivity, steps in the process related to the knowledge source preparation and metamodel creation process were checked and evaluated by two senior researchers who published scientific papers related to metamodels in top-tier IS and software engineering journals. The evaluation and refinement of the metamodel by these two researchers took place during February 2015 to October 2015 and is documented in Chapter 4, Appendices A, B, C, D, and E.

4.3

Development of MLSAC Tailoring Procedure

The following subsections present an overview of concepts related to method tailoring

124


and results of executing task Development of MLSAC Tailoring Procedure. 4.3.1 Overview on Method Tailoring Concepts As mentioned in Section 2.2.9, organisations may set an IT plan to move their legacy applications to the cloud. However, the actual migration requires a systematic method which guides IT developers to carry out such a transition to meet migration goals. In Section 2.3, a dozen cloud migration methods proposed by academia and industry were reviewed. They define a collection of fixed activities for planning, feasibility analysis, identifying candidate cloud services, re-engineering, testing, and monitoring applications that are to utilise cloud services. While methods agree on the aforementioned activities, they differ regarding the focus of their proposed process model, scope, and application domain. Additionally, a method may offer strengths in particular kind of service delivery model, such as IaaS, SaaS, or PaaS and, on the other hand, lack some weaknesses for other migration models. For example, a method might be suitable for moving large and distributed workloads from legacy data centres to public IaaS whilst another might be best suited to enable applications to work as a private SaaS. Accordingly, a realistic method should be configurable and consolidate existing methods to be applicable in different service delivery models and migration contingencies/goals. According to the discussion in Section 2.2.9, there is no universally superior or applicable method for all cloud migration scenarios. In situations like this, creating situation-specific methods that fit several existing migration scenarios would be beneficial. The literature review (Section 2.4) reveals that issues surrounding method tailoring for cloud migration have not yet been adequately addressed. Utilised in MLSAC metamodel presented in Section 4.2, the second component of the framework is a method tailoring procedure which aids in creating, fine-tuning, maintaining, and sharing bespoke methods for particular cloud migration scenarios. The proposed procedure is inspired by the method engineering approach (Section 2.5.2.3). While the MLSAC tailoring method uses the metamodel, it is viewed as a class of the Paradigmbased method tailoring approach (Section 2.5.2.3). The next section explains the procedure steps.

125


4.3.2 MLSAC Method Tailoring Procedure The proposed tailoring procedure relies on the metamodel component presented in Section 4.2 (Table 4-9 to Table 4-12). The tailoring procedure takes place in some complementary steps as depicted in Figure 4-7. In this figure, the metamodel includes the guideline table (Table 4-13) and relationships (Appendix E) used during the tailoring procedure. In the following, a fictitious scenario is used to clarify the procedure steps.

Figure ‎4-7 An overview of the method tailoring procedure

Step 1. Setting Migration Parameters. The input to the MLSAC are parameters including (i) a method name and description, (ii) migration types as described in Section 2.1.3, and (iii) a migration phase such as Plan, Define, and Enable as defined in Section 4.1.5. For example, suppose a development team plans to deploy and run a

126


legacy application in EC2 Amazon cloud servers. This is a virtual-machine-based migration of a legacy application using IaaS model, classified as migration type V (Section 2.1.3). In this scenario, the focus of developers is Enable phase and there is no concern about other phases of the migration. A well-structured method can assist developers with all relevant tasks to be carried out to make the legacy cloud-enabled. Step 2. Metamodel Instantiation: In this step, a vertical transformation occurs where the metamodel as the model at M2-level is instantiated to a new method as a target model at M1-level according to MOF modelling framework (Section 2.5.2.4). The sourced input parameters in Step 1 are used to retrieve the classes of relevant constructs from the repository. In order to identify relevant constructs from the database, the defined guidelines in Section 4.2.5 (Table 4-13) are used. In this fictitious example, relevant constructs to the migration Type V and Enable Phase in the MLSAC metamodel are suggested for the inclusion in the new method. These constructs are Resolve Incompatibilities (including subclasses Refactor Codes, Develop Integrator, and Adapt Data), Encrypt/Decrypt Entities

(including

subclasses

Encrypt

Database,

Obfuscate

Codes,

and

Encrypt/Decrypt Messages), Enable Elasticity, Test Application (including all test subclasses), Configure Network, and Deploy Application Components. Additionally, regarding migration Type V, some constructs are specified as mandatory, situational, or unnecessary to be carried out in the created method (Table 4-13). As it can be seen in Table 4-14, Deploy Application Components is a mandatory task as denoted by the symbol √. On the other hand, the incorporation of tasks related to incompatibility resolution is subject to the choice of a cloud platform denoted by symbol (√). That is, if legacy components are to be bound to specific cloud services, potential incompatibilities between the legacy and these services should be identified and subsequently resolved through adaptation mechanisms. Note that the information in Table 4-14 is sourced from the guideline Table 4-13. At the end of this step, the new method contains a set of constructs and their definitions reused from the metamodel.

127

Chapter 4. Development of the MLSAC Framework Table ‎4-14 List of the MLSAC metamodel constructs for inclusion in the new method Construct Adapt Data

(√)

Deploy Application Components

√

Develop Integrators

(√)

Enable Elasticity

(√)

Encrypt/Decrypt Database

(√)

Encrypt/Decrypt Message

(√)

Obfuscate Codes

(√)

Re-configure Network

√

Refactor Codes

(√)

Test Interoperability

(√)

Test Multi-tenancy

×

Test Connectivity

Situation

Migration Type V

Network

(√)

Test Performance

(√)

Test Scalability

(√)

Test Security

(√)

The incorporation of this task for the migration type V depends on the choice of a cloud platform. Mandatory The incorporation of this task depends on the choice of a cloud platform and required effort to refactor/modify legacy codes. If the code refactoring, as supported by Refactor Codes, is costly, then developing integrators/adaptors can be served as an alternative solution to hide incompatibilities. The incorporation of this task in the migration types V depends on a need for the application elasticity. The incorporation of this task in the migration types depends on the security requirement. The incorporation of this task in the migration types depends on the security requirement. The incorporation of this task into the migration process for migration types I, II, and V depends on security requirements. Mandatory. The incorporation of this task depends on the choice of a cloud platform. It depends on the choice of cloud platform. The incorporation of this task into the migration type V is not required. The incorporation of this task into the migration types depends on a need for the connectivity between migrated and nonemigrated components. The incorporation of this task into the migration types depends on a need for application performance in the cloud. The incorporation of this task into the migration types depends on a need for application scalability in the cloud. The incorporation of this task into the migration types depends on a need for application security in the cloud.

Step 3. Method Configuration. As shown in Figure 4-7, different sub-steps may be performed to accommodate migration method needs such as (i) adding new constructs to the created method if the pre-existing constructs in the repository are insufficient to support a new method for a given migration scenario (ii) extending existing constructs with new sub-constructs through the notion of inheritance, (iii) adding supportive (alternative) techniques to indicate how to operationalise the abstract constructs, and (iv) defining a specific flow among constructs to show their sequence. Regarding MOF modelling framework (Section 2.5.2.5), in all abovementioned sub-steps, a horisonatal transformation occurs at M1-level in the sense that the current version of the method as the source model is refined to its next version of the target model. The following describes these sub-steps. Firstly, in some situations, there is no need to include all suggested constructs in the created method and hence they are removed. Given the stated example, if the legacy

128


data layer is compatible with Amazon Relational Database Service and its APIs, there is no need to incorporate relevant tasks for the data adaptation. Accordingly, the construct Adapt Data is removed from the method. Other than that, the subclasses Encrypt/Decrypt Entities may not need to be included. Secondly, MLSAC tailoring procedure allows for adding new constructs such as phase, tasks, and work-products, which might not be supported by the metamodel, to the method from various sources or previous legacy to cloud migration experience. As defined in Section 4.1.2, when the method is enacted by IT developers, different workproducts are produced and refined by tasks during the migration process. Besides the pre-existing work-product constructs in the repository, new work-products can be defined that are unique to the method. Thirdly, through the notion of inheritance, originating from the object-oriented software development (Meyer, 1988), existing constructs in a method can be extended, thereby improving the structuring of the method and reuse of existing constructs. In the case of method designer from his/her experience defining a particular type of code refactoring developers would need to be aware of updating the legacy APIs to make them compatible with EC2 APIs. Such a potential incompatibility might be syntactic or semantic. The method designer can add a new subclass named Update APIs and Framework under the construct Refactor Codes in Enable Phase. Fourthly, as described in Section 4.2, the aim of the proposed metamodel was to avoid narrowing to technical and platform specific details in every situation-specific cloud migration scenario. The MLSAC tailoring component gives the ability of defining arbitrary implementation techniques to operationalise method task constructs. Returning to the example, supposing a networking adaptation is required for connecting other local organisational applications to the migrated application to EC2 Amazon; the following technique is defined to carry out construct Reconfigure Network: “The network should be divided into a total of 4 subnets across 2 Amazon Web Service availability zones in a single Amazon Web Service region. Each availability zoom should have a public subnet that users connected to, a private subnet for the application tier, a second private subnet for the database tier, and finally a separate subnet for the bastion hosts. Also, the local firewall should be set to open new ports.

129


These ports allow developers and administrator to connect to Amazon Web Service. The connection string to the database should also be updated to connect Amazon server”. Another aspect of tailoring procedure is to define and assign different alternative implementation techniques to a construct, allowing freedom to compare and choose the most appropriate implementation techniques for the scenario. Again, in the exemplar method, assume the designer wants to define resource provision techniques related to the construct Enable Elasticity so that developers can operationalise it later. He/she can borrow many existing resource provision techniques for this construct based on the cloud computing literature (Lorido-Botran et al., 2014, Galante and Bona, 2012, LoridoBotrán et al., 2012). The method designer can define three scaling techniques: (i) Reactive scaling where developers define a set of threshold-based scaling rules for the resource acquisition and release which requires a deep knowledge of the application resource utilisation patterns, (ii) Proactive scaling where developers use observation and prediction techniques to anticipate workload, and (iii) Hybrid scaling where a combination of reactive and proactive techniques are used to determine when to get a resource during short and long period of application execution. Step 4. Method Export. Once the method configuration step is finalised, the designer can store the method in the database on a computer or export it as an XML document (Mendling and Nüttgens, 2006). XML is a common format to represent models and facilitates interoperability and machine-readability of models. Using an XML format gives MLSAC the capability of exporting created method across development communities and different modelling platforms. As shown by dash arrow in Figure 4-7, the abovementioned sequential steps can be conducted iteratively. A method designer may evaluate the created method by getting feedback from team members and then resume method configuration at different stages of a cloud migration process. Chapter 8 shows how the abovementioned steps are operationalised through interactive forms by the MLSAC prototype.

130


4.4

Summary

This chapter has reported the outcome of the first two tasks of Phase2. It started with developing the first component of the MLSAC framework is the MLSAC metamodel, containing reusable constructs required for incorporation into the migration process without providing technical and scenario-specific details. Defining operationalisation techniques for the constructs are left to each individual metamodel instantiation where users can extend and refine the constructs regarding specific characteristics of a cloud migration scenario. The metamodel is integrated with a guideline table showing the connection between different migration types and the metamodel constructs. The guideline table helps users of the MLSAC metamodel know when a construct should be incorporated into the migration process regarding migration types. The chapter also defined the MLSAC tailoring procedure for situational method creation in particular cloud migration scenarios. The procedure is in line with the paradigm-based technique for situational method construction, as it relies on the reuse and configuration of metamodel constructs to represent and define new methods. The metamodel components developed in this chapter are evaluated in chapters 5, 6, and 7. The tailoring procedure component is implemented and evaluated in Chapter 8.

131

Chapter 5. Evaluation (I) of MLSAC Framework

Chapter 5.

Evaluation (I) of MLSAC Framework

No amount of experimentation can ever prove me right; a single experiment can prove me wrong - Albert Einstein This chapter reports the results of Evaluation (I) of MLSAC Framework. It starts with a brief description of the procedure for conducting this task (Section 5.1) and continues with reporting the task execution and findings in sections 5.2 to 5.6, a discussion on rating and ranking in Section 5.7, concluding in Section 5.7.

5.1

Evaluation Procedure

As mentioned in Section 3.2, the objectives of this evaluation were to ask qualified cloud computing experts to: — Rate the level of perceived importance of the constructs in the metamodel, — Provide comments, if any, on the constructs that they believe are important, and —Suggest, if any, additional constructs which had not been included in the metamodel. As visualised in Figure 5-1, this task includes the design of a Web-based questionnaire survey (sections 5.2 and 5.3), running the survey and collecting data from respondents (Section 5.4), analysing responses including six sub steps (Section 5.5). The outcome of the evaluation is the next refined version of the MLSAC framework.

132


Figure ‎5-1 Procedure for the evaluation (I) of MLSAC framework

5.2

Step 1—Survey Design

A Web-based survey was designed using Qualtrics (Snow and Mann, 2013), a survey designer software able to capture survey results. The questionnaire had two parts. In the first part, common terminologies used in the survey such as ISD methods, legacy application, and the legacy application migration to the cloud were provided. The second part included a list of questions asking respondents to rate the level of importance of each construct for inclusion in an ideal generic cloud migration reference model using a 1–7 Likert scale: 1 for not-at-all-important, 2 for very unimportant, 3 for somewhat unimportant, 4 for neither important nor unimportant, 5 somewhat important, 6 important, and 7 extremely important. For each construct, a simple definition was provided to help respondents to get a better understanding of the construct and the scope

133


of the questions. In addition, they could provide additional comments and suggest any missing constructs that should be added in the metamodel. The metamodel was designed to be sufficiently comprehensive and to encompass highlevel constructs. Therefore, it was not feasible to include all constructs in the survey as it would have made the survey too long and time consuming for respondents. Therefore, as shown in Figure 5-2 only super-classes highlighted with blue were rendered in the survey. For example, the super-class Test Application was included in the survey instead of its sub-classes Test Network Connectivity, Test Scalability, Test MultiTenancy, Test Security, Test Performance, Test Interoperability, and Test Designed Architecture. As another example, the super-class Analyse Context, which has five subclasses in the metamodel, focusing on a particular aspect of cloud migration feasibility such as cost and organisational change, was added in the survey as the representative construct. Other super-classes included in the survey were Analyse Migration Requirements and Test. According to Andrikopoulos [S65], identifying possible incompatibilities that might be triggered due to the adoption of migration types (sections 2.1.3 and 4.1.6) are important concerns during the migration process. In Figure 5-2, the super-class Resolve Incompatibilities captures the above concerns using three sub-classes Adapt Data, Refactor Codes, and Develop Integrators (Section 4.2.3) where each sub-class refers to necessary adaptations required for the layers of a legacy application. To assess their importance, all these sub-classes were included in the survey. In total, the following constructs were included in the survey: Recover Legacy Application Knowledge, Analyse Migration Requirement, Decouple Application Parts, Rebalance Application Components, Synchronise Application Parts, Test Application, Choose Cloud Platform/Provider, Design Cloud Solution, Refactor Codes, Analyse Context, Enable Elasticity, Encrypt Database, Adapt Data, Develop Integrators, Identify Incompatibilities, Encrypt/Decrypt Message, Define Plan, Reconfiguration Network, Make Application Stateless, Isolate Tenant, Handle Transient Faults, Application Templates, Cloud Solution Architecture, Legacy Application Model, Migration Requirements, Migration Plan, and Virtual Machine Specification.

134


Figure ‎5-2 Constructs presented in the survey highlighted with blue colour

135


5.3

Step 2—Pilot Survey

In relation to the Pilot Survey, the objective was to assess the clarity, structure, terminologies, and wording of the survey questions. An informal presentation of the survey was held to a group of domain experts who were asked to comment on the above aspects. Four experts were actively involved in this study including one expert with eight years’ experience in using Amazon services, one with seven years’ experience in IBM, one with three years’ experience in developing cloud software systems in the banking sector, and the last one was the editor-in-chief of a cloud-related academic journal. Respondents provided minor comments to improve the survey such as splitting long sentences into two or more sentences, changing the structure/sequence of the questions, and some grammatical changes to the questions. Their feedback was analysed and applied accordingly. The survey was launched and made available to respondents and took 30 to 40 minutes to complete. The final version of the survey can be found in Appendix F.

5.4

Step 3—Data Collection

The survey was undertaken from October 2014 to February 2015. It was sent through email to cloud computing experts who had a profile on social networks related to cloud computing such as LinkedIn, Twitter, and Facebook. The target population included those who had real experience of moving to cloud environments as well as academics who had published papers in journals and conference proceedings related to the cloud migration. To apply these criteria, prior to the recruitment of each participant, his/her online profile was screened to ensure if he/she had sufficient experience to contribute to the survey. Moreover, in order to increase the credibility of the collected responses, a purposeful sampling technique (Patton, 1990) was used through an inquiry email. The objective was to directly ask the candidate respondent about his/her cloud migration experience as well as their availability to participate in the survey. If the respondent’s answer and profile were satisfactory, the survey and the invitation letter were sent through a second email (see Appendix F for Participant Information Sheet and Consent Form). Close to

136


the end of the data collection period, a friendly reminder e-mail was sent to respondents who had not answered the survey. In total 515 experts were initially invited to participate in the survey and 144 respondents answered the survey. Of the 144 responses, 104 were usable after excluding incomplete answer sheets, giving a final response rate of 20%. The respondents were from 32 countries, with an average 3.8 years’ of experience, accounting for a collective 405 years of experience in the field of cloud computing. Table 5-1 shows the respondents’ diverse skillset and industrial sectors. Table ‎5-1 Descriptive statistics of survey respondents (n = 104) Variable

Experts title

Experience in software development

Experience and knowledge of software development methods Experience in cloud computing (e.g. service delivery models IaaS, SaaS, PaaS)

Industry sectors

Expertise Software developer Software architect Project manager Cloud consultant Academic instructor System analyst Academic research assistance Business architect Database designer Business process consultant Business decision maker

39 36 23 24 19 19 13 12 8 6 5

Count

Statistics % 18.5 16.6 10.64 11.1 8.7 8.7 6 5.5 3.7 2.7 2.3

Less than 3 years 4 to 8 years 9 to13 years More than 14 years

10 31 31 32

9.4 30 29.2 30.1

years =14 years

29 36 24 14

27.3 34 22.6 13.2

Less than 2 years 2-4 years > 4 years

12 52 41

11.3 48.1 38.6

Energy Financial Health Care Industrials (e.g. Goods, Professional Services, Transportation) Information technology Material Telecommunication Utilities Consumer discretionary

12 30 13 6 75 2 26 17 9

5.3 14 5.8 2.7 33.5 0.89 11.6 7.5 4

* Industry sectors obtained from Wikipedia http://en.wikipedia.org/wiki/global_industry_classification_Standard (last access September 2015)

5.5

Step 4—Analysis of Collected Responses

According to DP1 (Section 2.5.3.1), the metamodel should capture important and sound methodological constructs relevant for incorporation into a typical process of legacy

137


migration to the cloud. Taking DP1 into account, the objective of the data analysis was to assess whether the metamodel constructs were perceived as important by respondents, rated as equal to or more than the threshold 5, i.e. somewhat important. The null and alternative hypothesises were defined to assess this argument, i.e. H0: the mean of the importance of each construct is = 5 vs. H1: the mean of the importance of each construct is significantly > 5. The premise of this research hypothesis is that if a construct is rated equal or more than the mid-point 5 (somewhat important) by respondents, then it is perceived as important. Such a premise is consistent with the study by (Babaei et al., 2015), which uses a threshold to examine challenges of enterprise resource planning implementation in large organisations. This is also consistent with (Fung and Low, 2009)’s assessment of methodological requirements for dynamic evolution in composition-based distributed systems. The One Sample T-Test was suitable for determining if the mean of a sample data is different from a particular value (Morgan et al., 2004). Several assumptions were checked before using this test. Firstly, the normality assumption of the sample was checked using Kolmogorov–Smirnov test (Lilliefors, 1967). This detected that the collected data deviates from the normality assumption. Nevertheless, regarding the central limit theorem (Rosenblatt, 1956), a sufficiently large sampling distribution, N=104 in this case, will approximately have a normal distribution. This argument has also been confirmed by a variety of existing simulation results that shown parametric tests are not sensitive to the non-normality assumption (Glass et al., 1972, Lix et al., 1996). Secondly, One Sample T-Test assumes that variables are measured at a ratio level. As our sample size was large (N = 104), a Likert-type scale can be used to approximate a continuous scale. Finally, One Sample T-Test assumes that the responses are collected independently in the sense that respondents are randomly selected and individually participate in the survey. This assumption was also true for the current data collection as no respondent was aware of the identity of the final set of respondents. Once the assumptions of One Sample T-Test were satisfied, the test for the statistical analysis was applied using SPSS statistical software. Table 5-2 shows the descriptive statistics and the results of One Sample T-Test’s with p < .05 for each construct. Since the hypothesis was formulated for a right-tailed test, the p values in Table 5-2 were

138


divided by 2. From column six of Table 5-2, it can be observed that the majority of the defined constructs in the MLSAC metamodel, i.e. 27 out of 29, were rated statistically of significant importance (p < .05) by the respondents. This confirmed the relevance and importance of the constructs for the inclusion in the MLSAC metamodel, as aimed by DP1. The task construct Tenant Isolation (t-test statistic of= -1.499, p-value of=0.06) and the work-product construct Virtual Machine Specification (t-test statistic of=0.513, p-value of =0.30) were perceived not important by the respondents. Although these constructs were liable for the exclusion from the MLSAC metamodel, it was decided to keep them in the metamodel regarding the objective of the completeness of the metamodel as defined by DP1.

139

Chapter 5. Evaluation (I) of MLSAC Framework Table ‎5-2 Descriptive statistics for the constructs and the results of one sample T-Test for each construct

Work-Products

Tasks

# Metamodel’s construct 1) Adapt Data 2) Analyse Context 3) Analyse Migration Requirements 4) Choose Cloud Platform/Provider 5) Configure Network 6) Decouple Application Components 7) Define Plan 8) Design Cloud Solution 9) Develop Integrators 10) Deploy Application 11) Enable Elasticity 12) Encrypt Database 13) Encrypt/Decrypt Messages 14) Handle Transient Faults 15) Identify Incompatibilities 16) Make Application Stateless 17) Obfuscate Code 18) Rebalance Application Components 19) Recover Legacy Application Knowledge 20) Refactor Codes 21) Synchronise/Replicate Application Parts 22) Isolate Tenants 23) Test Application 24) Application Templates 25) Cloud Solution Architecture 26) Legacy Application Model 27) Migration Plan 28) Migration Requirements 29) Virtual Machine Specification * p-values were divided by two as t-test was one-tailed

Mean 4.6250 5.6827 6.1346 5.9519 5.7476 5.9417 6.3365 6.2692 4.4706 5.2404 5.8641 5.2692 5.6923 5.6635 5.9712 5.6346 4.6311 5.3786 6.1346 4.6505 5.8462 4.8269 6.0865 5.3725 5.9615 5.7115 6.1058 5.9135 5.0686

140

Std. Deviation 1.16742 .97805 .75115 .92830 1.03581 .94791 .67710 .85025 .95135 1.31086 .95022 1.28645 1.07104 1.05766 .93950 1.19105 1.54025 1.18086 .98590 .85988 .93237 1.17781 .71204 1.16824 1.00410 1.11192 .82342 .96653 1.35164

T-Statistic value -3.276 7.118 15.404 10.458 7.325 10.083 20.130 15.223 -5.620 1.870 9.229 2.134 6.592 6.397 10.542 5.434 -2.431 3.254 11.736 -4.125 9.255 -1.499 15.562 3.221 9.766 6.526 13.695 9.638 .513

p-value 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.032 0.000 0.017 0.000 0.000 0.000 0.000 0.008 0.001 0.000 0.000 0.000 0.068 0.000 0.001 0.000 0.000 0.000 0.000 0.3045

Chapter 5. Evaluation (I) of MLSAC Framework In the next step of data analysis, constructs were ranked according to their means. This was indicative of the importance and relevance of the construct compared to other constructs in the conceptual model (from highest to lowest ranking) as shown in Table 5-3. The three highest ranked constructs were Define Plan, Design Cloud Solution, and Analyse Migration Requirements. In contrast, the three lowest ranked were Obfuscate Code, Adapt Database, and Developing Integrator. Table ‎5-3 Ranking constructs based on the mean

# 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16) 17) 18) 19) 20) 21) 22) 23) 24) 25) 26) 27) 28) 29)

Metamodel’s construct Define Plan Design Cloud Solution Analyse Migration Requirements Recover Legacy Application Knowledge Migration Plan Application Testing Identify Incompatibilities Cloud Solution Architecture Choose Cloud Platform/Provider Decouple Application Components Migration Requirements Enable Elasticity Synchronize/Replicate Application Components Reconfigure Network Legacy Application Model Encrypt/Decrypt Messages Analyse Context Handle Transient Faults Make Application Stateless Rebalance Application Components Application Templates Encrypt Database Deploy Application Virtual Machine Specification Isolate Tenant Refactor Codes Obfuscate Code Adapt Data Develop Integrators

Mean 6.3365 6.2692 6.1346 6.1346 6.1058 6.0865 5.9712 5.9615 5.9519 5.9417 5.9135 5.8641 5.8462 5.7476 5.7115 5.6923 5.6827 5.6635 5.6346 5.3786 5.3725 5.2692 5.2404 5.0686 4.8269 4.6505 4.6311 4.6250 4.4706

As the third step of data analysis, a post-hoc analysis was conducted to test the power2 of the given statistical results with respect to the type of statistical test, sample size, and significant level 0.05. Conventionally, a test with a power greater than 0.8 (or ß