Information Technology Reference
In-Depth Information
important requirements that we identified. More specifically, as the method-
ology focuses on Oracle solutions, it only considers the relational database
management system of Oracle as the target data store and the following rela-
tional data stores as the source databases for the migration: Microsoft SQL
Server (http://www.microsoft.com/en-us/sqlserver), Sybase (http://www.
sybase.com), IBM DB2 (http://www.ibm.com/software/data/db2), and IBM
Informix (http://www.ibm.com/software/data/informix/). All of these data-
bases are data stores supporting fine-grained interactions through SQL. It
is unclear whether the methodology also supports data services because no
information can be found on this aspect in Laszewski and Nauduri's work
(2011) (F R 1 ). The methodology is not independent from the database technol-
ogy as it focuses on a small set of relational databases and does not support
NoSQL approaches (FR 3 ). Moreover, the methodology is limited to the pure
outsourcing of the database layer to the cloud and does not consider the con-
text and specifics of migration scenarios such as cloud bursting, backup, and
archiving (FR 6 ). As concrete migration scenarios are not considered, their
specifics and the context cannot be considered for the guidance and recom-
mendation toward refactoring of the application architecture. In addition, the
guidance and recommendations for the required adaptations of the applica-
tion architecture during the migration are limited since the migration meth-
odology (Laszewski and Nauduri, 2011) considers only one vendor-specific
relational target data store and a small subset of vendor-specific relational
data stores as the source data store (FR 7 ). The vendor specificity also has the
consequence that the methodology does not consider the reusability aspect
with respect to the integration or combination of this methodology with other
existing proposals for migration to the cloud (NFR 2 ).
To address these deficiencies, in the following we propose a vendor- and
database technology-independent step-by-step methodology that refines
and adapts the one proposed by Laszewski and Nauduri (2011). Figure  5.2
provides an overview of the phases of the methodology proposed that we
adapted and refined. Figure 5.3 provides an overview of our proposal con-
sisting of seven steps. All steps are semiautomatic, in the sense that a human
(e.g., the application developer in charge of the migration) has to provide
input and follow the recommendations and guidelines provided by the
methodology. Figure  5.3 also shows the mapping between the proposed
methodology and the one in Laszewski and Nauduri's 2011 work. As can
be seen, no direct support for the Test and Optimization phases is provided
by our proposal since there are no identified requirements explicitly requir-
ing these phases. The impact of not supporting these phases is evaluated in
Section 5.5. The steps of the methodology are discussed next.
5.4.2.1 Step 1: Select Migration Scenario
The first step in our proposed methodology is the selection of the migration
scenario . For this purpose, we use the 10 Cloud Data Migration Scenarios
Search WWH ::




Custom Search