Role of contextual properties in enterprise service migration to cloud computing

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. 2013; 25:2455–2470Published online 28 June 2013 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/cpe.3085

SPECIAL ISSUE PAPER

Role of contextual properties in enterprise service migration tocloud computing

Khaled M. Khan*,† and Qutaibah Malluhi

Department of Computer Science and Engineering, Qatar University, Doha, Qatar

SUMMARY

This paper attempts to identify the role of contextual properties of enterprise systems architecture inrelation to service migration to cloud computing. In a cloud-based service architecture, the shift ofownership, scope, and control over architectural elements from consumers to cloud providers has aprofound impact on ways cloud consumers design and manage their systems architecture. In thisperspective, we introduce the concepts of architectural scope, ownership, and control as the contextualproperties of systems architecture. The paper explores ways in which these properties can be mappedinto a quantifiable framework that could be used to measure the degree of changes of contextualproperties due to service migration to cloud computing. We seek here to address the service migrationproblems from a different perspective, namely, focusing on the contextual properties of architecturalelements. Copyright © 2013 John Wiley & Sons, Ltd.

Received 16 May 2013; Accepted 4 June 2013

KEY WORDS: cloud computing; enterprise service migration; contextual properties; architectural properties;software architecture

1. INTRODUCTION

Cloud computing offers a range of simplified services that are flexible enough for consumers to choosefrom. The main idea behind cloud computing is to provide dynamically scalable services such assoftware, database, security, hardware, platform, and storage to enterprises. Adopting cloudcomputing services appears to be a worthwhile business option for enterprises in order to exploit theadvantages of scalability, elasticity of resources, and cost reduction. Instead of running applicationsoftware in their machines and acquiring powerful computers, enterprises can use applicationsoftware as well as computers owned and managed by someone else. Consumers need not havemuch expertise in or control over managing the computing resources that support the services theyuse for their businesses.

Despite the obvious benefits provided by cloud computing, one of the challenges is how to migrateexisting enterprise computing services to cloud computing effectively without disrupting currentbusiness processes. The open question is as follows: what is the role of enterprises in managingsystems architecture in a cloud computing setting? In current practices, software architecture consistsof several elements that are mostly owned, used, and controlled by the enterprise that uses them.

*Correspondence to: Khaled M. Khan, Department of Computer Science and Engineering, Qatar University, Doha, Qatar.†E-mail: [email protected]

Copyright © 2013 John Wiley & Sons, Ltd.

2456 K. M. KHAN AND Q. MALLUHI

These elements are primarily confined within the boundary of the enterprise that owns and controlsthem. In this setting, organizations have full control over and ownership of their architectural elements.

The scope of a systems architecture in an organization is well defined. The cloud computingparadigm seems to change this very scope and the associated responsibilities of enterprises. Cloudcomputing seems to require consumers to relinquish their ownership of and control over mostarchitectural elements to cloud providers. This perceived change can somehow influence the wayscomputing resources and business data are used, manipulated, shared, and managed by enterprises.

Although the migration from the localized computing environment to cloud computing iscompelling for enterprises, it poses some systems-related challenges, too. These include identifyingcontextual properties of software architecture, finding and understanding the issue of consumer-controlled versus cloud-controlled architectural elements, and interoperability of enterprise policies.The definition of cloud-enabled systems architecture cannot be limited only to components,connectors, and styles; rather, the contexts such as ownership, controlling entity, and scope ofarchitectural elements need to be considered. These contextual properties do not have any directobservable manifestation in a systems architecture but do point out something important for allstakeholders in order to understand the impact of service migration to cloud computing. Thisdefinitely requires systems architects to rethink the current practices of architecting systems in lightof cloud-enabled architectural challenges previously unaccounted for.

In cloud computing, the scope of a software architecture includes the client enterprise as well as thecloud provider at different points of time. This changing architectural scope has also influence on twoother contextual properties: control over and ownership of architectural elements. For example, whenthe ownership of some architectural elements transfers from the client's organization to cloud provider,the clients control over those elements also changes. This changing landscape of contextual propertieshas an impact on the success of cloud integration and service management. Cloud consumers need tocreate a service integration model to help implement the service migration, evolution, and maintenancesuccessfully [10]. Without a thorough understanding of contextual properties in cloud-basedenvironments, such integration will remain a far reaching goal.

Cloud computing is a disrupting technology in a sense that it demands changes to the waysorganizations have so far enjoyed in designing and managing their software architecture to meettheir computing requirements. Many organizations may fail to identify the real impact of migratingtheir existing services to a cloud computing probably because of a lack of understanding of theunderlying contextual properties of systems architecture and their perceived influence. Existingknowledge and known properties of systems architecture are too shallow for enterprises tocomprehend the real impact of migrating their systems architecture to cloud computing.

There is a need for a deeper understanding of cloud-based systems architecture that enables cloudconsumers to adopt this paradigm without much hesitation. The migration of client services to cloudcomputing and its impact should be well understood by all stakeholders. In this paper, we examineconcepts and methodologies of systems architecture in light of cloud computing environment in orderto understand the contextual properties of systems architecture. We need to know how architecturalproperties change for the dynamically instantiated, distributed, and ephemeral services [14].

There is no doubt that in order to map their existing computing needs to cloud services,organizations should perform systems architecture reconstruction and streamlining. In order toenable enterprises to achieve this, we attempt to flesh out contextual properties of softwarearchitecture that are vital for all stakeholders to understand the migration impact of existingarchitecture to a cloud-based environment. The idea of considering contextual properties arisesbecause of environmental changes, not necessarily because of technical drivers. As a result, weexamine the changing landscape of architectural elements and explore their contextual properties ina cloud-based environment.

The literature has made very little observations on the changing nature of contextual properties ofarchitectural elements that makes enterprises to hesitate in migrating their existing services to cloud.The unstated assumption is that migrating services to cloud is often considered purely as a technicaland business decision. We observe that the decision to migrate enterprise services to the cloudshould also be driven by the changing roles of contextual properties. Casual observations regardingthe migration of enterprise computing services to the cloud computing seem to assert that the

Copyright © 2013 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2013; 25:2455–2470DOI: 10.1002/cpe

ROLE OF CONTEXTUAL PROPERTIES IN SERVICE MIGRATION TO CLOUD 2457

identification of the shifting nature of contextual properties associated with systems architecture couldresult in improved understanding of enterprises about cloud computing. In this paper, we use enterpriseand organization interchangeably. By the term systems architecture, we mean a broader concept ofarchitecture that includes software units as well as hardware devices.

2. RELATED WORK

There is no systematic study yet of software architecture in relation to migration of existing softwarearchitecture to cloud computing. This topic is alarmingly absent in research forums. Becauseresearch has not focused much on contextual properties of software architecture, this paper attemptsto fill this gap. The field of legacy systems migration has made a lot of progress over the last twodecades in particular. In this regard, a good number of techniques and tools have been developed inorder to reconstruct software. The challenges posed to enterprises by cloud computing in relation tomigrating enterprise services to cloud providers has not been addressed adequately yet. There isvirtually no de facto standard process for migrating existing services to the cloud and integratingthem with the enterprise systems architecture [5].

The challenging issue of cloud computing and enterprise architecture was probably first raised inKhan and Gangavarapu' (2009) study [21]. It showed how different cloud service models haveimpact on enterprise systems. Although the paper does not propose any new method, it clearlypointed out the issues that need to be addressed. The work reported in Kaisler and Money's (2011)study [19] also raised various issues in relation to service migration to the cloud. It does not provideany concrete framework; however, it examines security and integration issues associated withservice migration. In current practices, the most common design approach for cloud-enabledenterprise service architectures follows a layered approach used in enterprise service-orientedarchitecture [11]. The work of Tang et al. (2010) [15] proposed a way to extend the enterpriseservice-oriented architecture to a new hybrid architectural style by combining it with the cloudcomputing service provisions. It is expected that the proposed hybrid architectural style couldrepresent a concrete cloud-based enterprise service architecture that uses SOA architecturalelements, design patterns, and quality attributes. However, the paper does not address the migrationissue to the cloud. A service-oriented cloud computing architecture has been proposed in the studyof Tsai et al. [7], but it fails to address the migration of services from enterprise to cloud.

For multitenant systems, some noteworthy architectural styles are proposed such as representationalstate transfer [4] and Single Page Internet Application Architecture (SPIAR) [9]. Representational statetransfer focuses on the communicated data elements, whereas SPIAR emphasizes on interactive UI andon interaction between client and server. Another architectural style called SPOSAD [8] is proposedfor multitenant software applications. It primarily focuses on architectural constraints and discussesvarious trade-offs to consider. A cloud computing open architecture model comprising sevenprinciples has been proposed in the study of Zhang and Zhou (2009) [13]. The main objective of themodel is to motivate cloud vendors, cloud partners, and cloud consumers to work together on thebasis of these seven principles. The model is intended to bridge between SOA and virtualization inthe context of cloud computing ecosystem. An enterprise cloud-based architecture based ondistributed infrastructure to facilitate rapid prototyping and deployment of adaptive communicationservices is proposed in the study of Samimi et al. (2007) [12]. It attempted to combine adaptivemiddleware functionality with an overlay network substrate in order to support dynamic instantiationand reconfiguration of services.

3. ARCHITECTURAL ELEMENTS

A software service is a business application processing unit packaged into one or a set of softwaremodules. Each module is simply an implementation of the business process operation to deliver thespecified service(s). Software modules run on systems software, platform, and hardware devices.These also use storage and network facilities for data movement, data transient, and data archiving.



A software architecture delivers services by binding the software modules together using data andcontrol flows and provides defined structure for their governance. On the other hand, a systemsarchitecture takes into account software architecture and the underlying systems software andhardware devices. Thus, architectures of service-based systems could be classified into two types:software architecture and systems architecture.

3.1. Software architecture

A software architecture is a model that defines elements from which a system is constructed by usingrules of interactions and connectors [1,16]. More precisely, a software architecture is primarily builtfrom the following two elements [2]:

• Components: A component is an architectural element that performs some predefined functions, orrepresents specific information. Components are basically computational units with well-definedinterfaces such as modules, procedures, processes, filters; or pieces of information such as objects,data, and databases.

• Connectors: These are compositional elements for gluing the components together in an architecturaltopology. Examples of connectors include function calls, shared variables, messages, communicationprotocols, event broadcast, pipe, and streams.

Architectural styles are set of rules that mediate communication and interaction among componentsusing connectors. An architectural style guides the interactions among components in order to form ageometric layout of the software architecture. An architectural style basically defines a vocabulary ofcomponents, connectors, and their interactions [3]. Examples of architectural styles are pipe-and-filter, process model, and object-oriented. Different styles may produce different structureand topology.

Consider an example of a software system. A company called AnalyzerPro is specialized in DNAsequence analysis. It developed a customized DNA sequencing analysis software called DNAANALYZER that performs variant analysis of Sanger sequencing files such as .RSD, .ESD, .ab1, and .scf generated by various tools. It provides accurate analysis of DNA variants including medicalsequencing, and deconvolution of heterozygous indels. The software automatically deconvolutesheterozygous indels found in Sanger sequencing DNA reads into two clean traces for analysis. Itinvolves aligning sample trace to reference trace, detecting presence of heterozygous indels, anddeducing mutant sequence by subtracting reference from sample sequence. The algorithms heavilyrely on mathematical calculations such as the convolution, deconvolution, addition, and subtraction.

Figure 1 provides a simplified software architecture of the application using pipe-and-filterarchitectural style. The filters (ovals) are the architectural components, and the pipes (arrows) are theconnectors. The architectural components preprocess and align files are customized, whereas

Figure 1. Software architecture for detecting heterozygous indels.



the remaining architectural elements are standard software units. The rules of interaction in this styleare the following:

• Each filter (component) reads streams of data on its input and produces streams on its output channels;• Thepipes(connector)actas transmissionchannels for thestreams,carryingdata fromonefilter toanother;• Filters do not share state with other filters, hence are independent; and• The solid-line outer rectangle denotes the scope of the architecture in terms of the organizationalboundary of the company AnalyzerPro.

3.2. Systems architecture

Asystems architecture is a combined conceptualmodel comprising all hardware–software unitswith a varietyof elements such as software components, connectors, hardware devices, network, and storage. [17].It defines the structure and behavior of the entire computing system. The components of systemsarchitecture include computer, disks, components, and connectors of the software architecture. Theconnectors are network, communication protocols, and so on. Figure 2 shows a systems architectureof the DNA analysis system depicted in Figure 1. The software architecture is currently running onLinux platform using several servers, and processed DNA sequences (data) are stored in redundantarray of independent disks. All hardware devices belong to AnalyzerPro. The three filters used in thedetection of heterozygous indel module run on a IBM System z9 mainframe computer. Thepreprocessing and other filters are mounted on HP ProLiant ML 350 G6 servers. The storage isperformed on an IBM ServeRAID M5000. The bend corner rather smaller rectangles are thehardware devices of the system.

4. CONTEXTUAL PROPERTIES

Although the business goal of an organization remains the same, the contextual properties of itssoftware architecture may change because of the new operational environment in cloud computing.We identify some important contextual properties of software architecture, which were previouslyeither not identified or ignored due to lack of their relevancy. In an architecture, we can identify thethree contextual properties: architectural scope, ownership, and control. These have influences insystems architecture, in particular during the migration of services from one architecture to another.

An architectural element must have a scope in terms of its operating parameters. The element maybelong to one or more entities, and it must be controlled by one or more entities at different stages of itsservice. In cloud computing, an architectural element may be in one or both of these two stages in aparticular point of time: on-premise and off-premise. The stage of an architectural element is said tobe on-premise while it is within the boundary of the consumer's organization, whereas off-premise

Figure 2. Entire systems architecture for detecting heterozygous indels.



denotes the stage of the element while it is in the boundary of the cloud provider. The identification ofthese ‘shear lines’ between off-premise and on-premise provides clear boundaries between theenterprise and the cloud provider in an integrated service architecture.

We can model these further. A software architecture a includes a set of architectural elements(namely, components and connectors) {c1, c2,…,cn}, and each element ci is associated with twostages ci.s

0 = {ci.so,ci.s

f} where so denotes on-premise, and s f represents off-premise. Each of theseis associated with three contextual properties: scope, ownership, and control such as:

ci:so ¼ scope; ownership; controlf gci:s f ¼ scope; ownership; controlf g:

4.1. Architectural scope

In a particular point of time, an architectural element is located within the boundary of either theconsumer or cloud provider in either on-premise or off-premise stages, respectively. Architecturalscope refers to the physical distribution of an element and its surrounding parameters that it canhave an operational effect. The topology of an architecture may spread across several distributedlocations beyond the consumer organization at one of two different stages (on-premise, off-premise).That is, some of the architectural elements may be located outside of the consumer's organizationalboundary. For example, a process of a software architecture belonging to an organization may serveanother organization. In this case, the scope of the process includes another organization.

The example software architecture (Figure 1) of the DNA sequencing system is located in a singleorganization, that is, it is located within the perimeter of AnalyzerPro. In cloud context, a data flow cancarry data from consumer organization to cloud or vice versa. In that case, it can be in two differentstages; once on-premise and then off-premise while it is processed or stored in the cloud. The scopecan also be related to another contextual property, called ownership.

4.2. Ownership

Ownership means the possession of architectural elements along with the exclusive right of thepossessor to alienate that possession at its will. More specifically, the owner possesses an entirearchitecture or some of its elements at different stages. Ownership does not change stage fromon-premise to off-premise or vice versa. It is not possible for a data to have two differentownerships in two different stages. The ownership of a component is static across organizationalboundaries. An organization may use a software architecture or some of its elements that are ownedby another organization. In the systems architecture shown in Figure 3, all filters, pipes, and

has_scope

ownOrganization

org_name role location

Element

element_name type

function

M N

1 N

stage

controlNM

stage

(a) A conceptual model for capturing contextual properties

Stage

(b) A storage tempalte for capturing contextual properties

Element Scope Ownership Control

Figure 3. Conceptual schema for capturing contextual properties.



hardware devices are owned by AnalyzerPro. The company does not share its software componentsand hardware devices with any other organizations.

In most cases, the ownership has a strong bond with the scope of the architecture. If an architecturalelement is located within the scope of an organization, it is owned most likely by that organization.However, some elements can be localized within the perimeter of an organization, but the housingorganization does not own it. For example, an application running on a server may be locatedon-premise of the renting organization, but the software is owned by the lending organization.Ownership has also an interesting relationship with another contextual property known as control.

4.3. Control

The control means the ability and right of an organization to make design-related decision on thearchitecture as well as the architectural elements. The design decision may affect the operational aswell as structural aspects of the architecture. The controller of the architectural elements makes thedesign decisions such as modifications, maintenance, evolution, fixing bugs, and removing andadding elements in the architecture. The control over a static element cannot change at differentstages (on-premise and off-premise) of the service. The control is fixed because static elements donot move within the architecture. However, the control over data in motion can change from on-premise to off-premise, or vice versa because data flows from one organizational boundary to another.

Control is usually associated with the ownership. If an organization owns an element, it controls thatentity. In some cases, the control is also attached with the scope of the element. The boundary of thearchitecture determines which entity has control over it. However, this is not the case for the rented oroutsourced architectural elements, because although these are located within the boundary of anorganization, it does not control the element, rather the lending organization controls it. In ourexample, AnalyzerPro controls all architectural components and connectors.

The contextual properties mentioned previously have never been considered in systems architectureso far because of the uni-ownership and uni-control over them by enterprises. In a cloud-basedenvironment, it is interesting to see how these contextual properties of software architecture change,have an impact on cloud-enabled systems, how the architectural styles evolve to address the cloudcharacteristics, and how to balance the control over and ownership of various architectural elements.We explore some of these in the rest of the paper. A simple modeling tool such as an entity–relationship diagram is used to depict the relationships between different contextual properties of aservice software architecture: which organization owns which elements, their scope, and thecontrolling entities. Figure 3(a) is an example of such a conceptual model. According to the figure,an architectural element can only be owned by one organization; however, an element could belocated in more than one architectural boundary (scope) and controlled by more than oneorganization at different stages. Figure 3(b) provides an example of storage template for capturinginformation about the contextual properties. Table I specifies the contextual properties of thesystems architecture shown in Figure 2. In the table, ON means on-premise stage.

5. CLOUD SERVICE MODELS

Organizations migrating their existing services to the cloud should know how the control is shared,allocated, transferred among architectural elements, spread across organizational boundaries, howorganizational data interact with cloud-controlled processes in a cloud-enabled software architecture,and how the ownership affects the design decision of the system. In order to understand theseperspectives, we first understand the characteristics of the major cloud service models. Cloudcomputing can offer X as a service; three of them are considered the major service models:infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).

• Infrastructure as a service provides computer infrastructure–typically hardware-based servicessuch as storage, computer (CPU), and network. IaaS virtualizes hardware devices. The cloudprovider offers the infrastructure services in the form of a virtual machine instance. Virtualizationis the key architectural component in cloud computing for creating and managing the cloud-specific


Table I. Contextual properties of the system shown in Figure 2.

Element Scope Owner Control Stage

1 Load sample DNA AnalyzerPro AnalyzerPro AnalyzerPro On2 Obtained reference DNA AnalyzerPro AnalyzerPro AnalyzerPro On3 Preprocess AnalyzerPro AnalyzerPro AnalyzerPro On4 Align files AnalyzerPro AnalyzerPro AnalyzerPro On5 Deconvolution AnalyzerPro AnalyzerPro AnalyzerPro On6 Substraction AnalyzerPro AnalyzerPro AnalyzerPro On7 Storing detection results AnalyzerPro AnalyzerPro AnalyzerPro On8 Storing reference files AnalyzerPro AnalyzerPro AnalyzerPro On9 DNA files AnalyzerPro AnalyzerPro AnalyzerPro On10 Processed files AnalyzerPro AnalyzerPro AnalyzerPro On11 Aligned files AnalyzerPro AnalyzerPro AnalyzerPro On12 Reference DNA files AnalyzerPro AnalyzerPro AnalyzerPro On13 Deconvoluted data AnalyzerPro AnalyzerPro AnalyzerPro On14 Detection results AnalyzerPro AnalyzerPro AnalyzerPro On15 Sample DNA AnalyzerPro AnalyzerPro AnalyzerPro On16 HP ProLiant MP AnalyzerPro AnalyzerPro AnalyzerPro On17 IBM System z9 AnalyzerPro AnalyzerPro AnalyzerPro On18 IBM RAID M50000 AnalyzerPro AnalyzerPro AnalyzerPro On


virtual machines. Once created, the consumer can load any operating system and applicationsoftware on the virtual machine instance and load their data on the storage.

• In PaaS, the consumer uses the platform and tools provided by the cloud provider in order todesign, model, develop, and test application software. The service is made available with theunderlying required hardware and the operating system. Consumers of PaaS can develop theirapplications directly on the rented platform and elastically scale out as needed [6].

• Software as a service provides application software capabilities needed by consumers. SaaSprovides application resources that support services accessible to consumers. Examples are emailservices, Google maps, word processing, mathematical computation, customer recordmanagement, and enterprise resource planning. Software services can be requested on demandand can be integrated with other mash-up applications [7].

In brief, IaaS provides hardware devices, PaaS offers platform along with hardware devices and theoperating environment, and SaaS comes with application software including the underlying hardwareand platform.

6. SERVICE MIGRATION TO CLOUD

Service migration is the relocation of a particular software/hardware service from its current location(in enterprise) to another new location (cloud computing) outside the enterprise's boundary for aspecified duration. It requires moving the underlying software/hardware modules, devices, and evendata of the migrated services to the new processing site and removing completely or partially fromthe old site. It is similar to process migration as proposed in the study of Milojicic et al. [18]. Inservice migration, software modules along with data leave the consumer's direct control and scope[19]. Migration of existing enterprise services should not be viewed as an effort on its own but as aprocess of streamlining architectural elements of the existing services across organizational boundaries.

The service migration could be classified into two classes in terms of their type: customized servicesand standard services. Customized services cannot be migrated directly to SaaS of cloud computing. Itrequires the redevelopment or mounting the existing customized software to PaaS. However, thestandard software services could be readily migrated to SaaS because most standard services areavailable from cloud SaaS in which software is completely owned, delivered, and managed remotelyby cloud provider [20].



The migration of customized as well as standard services could be partial or full:

• In partial service migration, organizations may decide to use cloud computing for some of theirexisting services of its existing services. In partial migration, an existing software architectureacquires some (not all) standard software services from cloud. In this case, some services areretained under the control of the enterprise. It requires significant reconstruction of the existingsoftware architecture. In a partial service migration, the first step is to identify the architecturalelements of the specific outsourcing service. The process involves identifying the potentialarchitectural elements of the services that are to be migrated to cloud and finding theirdependencies between the remaining elements in the organization and the elements that make upthe candidate outsourced services to cloud. For a service to be migrated to cloud, the architecturalelements of that service should be self-contained and loosely coupled with the remainingarchitectural elements in the organization.

• In a full migration, all services of the entire architecture are outsourced to the cloud computing,that is, the core service components are outsourced to cloud. In both cases, all services within theorganization and in the cloud need to use a common data model. In partial outsourcing,organizations should have a clear idea about which architectural elements are owned and controlledby cloud computing in the newly migrated services. Figure 4 depicts a generic relationship betweenexisting software services and major cloud models in a service migration process.

6.1. A service migration process framework

We propose the following tasks that are involved in a service migration process.

• Identify candidate services: In this task, the enterprise decides which of its existing servicesshould be migrated to cloud and which elements should remain in the organization.

• Select cloud service model: It involves finding if the candidate service is a customized or a stan-dard one. If it is a customized service, a PaaS cloud service model should be selected. It requiresdevelopment and mounting of customized services on the PaaS platform. If the candidate serviceis a standard one, a SaaS cloud model is to be chosen.

• Identify residence services: This task identifies the architectural elements of the remainingresidence services in the enterprise. These services are not migrated.

• Find service dependency: It requires mapping out the dependency between the residence services andthe migrated services. It includes the development of an integration plan on how the architecturalelements of these two types of services should be communicated in terms of data and control flows.

• Identify contextual properties: This task identifies the contextual properties of each architecturalelements of services. This identification involves premigration and postmigration contextual

Existing softwareservices

Customizedservices

Standardservices

PaaS

SaaS

Partialmigration

Partialmigration

Full migration

IaaS

Cloud computing

Existing enterprise software services

Figure 4. Mapping between existing architecture and cloud models.



properties of the migrated services. This is necessary in order to see the changes of contextualproperties because of service migration to cloud.

The identified contextual properties are stored in the template proposed in Figure 4. Figure 5 showsthe proposed generic process framework for service migration. In this framework, other decisionfactors such as costing, performance, security, and trust properties of cloud providers have impact inthe migration decision process.

6.2. Cloud-based software architecture

Existing enterprise architectures are not designed to be distributed beyond the organizational boundary.A cloud-enabled architecture may comprise the consumer's on-premise as well as cloud resources suchas services, middleware, architectural elements, location, and the interactions of elements [5]. Thecontrol over architectural elements is the most important contextual property in cloud computing. Incloud architecture, the cloud provider has their own autonomous control flow of the system. In anon-cloud environment, the software systems and hardware devices are localized in the organizationthat uses it. Organizations have unified control flow in the architecture tuned to customize theirorganizational needs. These two practices are interwoven in a cloud-based system architecture. Incloud computing, organizations should restructure their existing architecture to adapt computingservices offered by cloud computing.

The architectural elements (infrastructure devices, software) are grouped into two distinct types in threecloud service models (PaaS, SaaS, and IaaS): consumer-controlled elements and cloud-controlledelements. The former are those that are controlled by cloud computing consumers, namelyorganizations. Whereas, the latter elements are controlled and managed by cloud providers, both in theoff-premise stage.

Figure 6 depicts the major cloud service models and their architectural elements that the cloudprovider controls.

• In PaaS, the cloud provider controls the hosting development environment such as modeling tools,compiler, and the operating system; whereas, the cloud consumer controls application software,process, and data.

• In SaaS, the consumer virtually relinquishes their control over all architectural elements to thecloud provider.

• In IaaS, the consumer-controlled architectural elements typically are data, process model,deployed application software, and operating platform. The provider controls the hardwaredevices such as computers, storage, and network. However, this may change from applicationto application. If the consumer receives software services in addition to infrastructure, the controlover most elements is held by the provider.

6.3. Service migration to cloud: an example

In order to take advantage of elasticity of resources and minimize its current running cost, AnalyzerProhas decided to outsource some of its existing computing resources used for the detection of

Identifycandidateservices

Selectcloud service

modelIdentify

residenceservices

Find service

dependencyIdentify

contextual properties

Figure 5. A service migration process framework.


data data flowprocess

Software architecture(SaaS)

System software(PaaS)

compiler operatingsystem

modellingtools

storage networkCPU

Computing Infrastructure(IaaS)

Figure 6. Mapping between high-level architectural elements and cloud models.


heterozygous indel to a cloud computing provider called CloudTrack. AnalyzerPro applies ourproposed migration process framework (except the last task) to its decision for service migration toCloudTrack. The process of identifying contextual properties is discussed in the next subsection.The resulting outputs are shown in Figure 7. The company has identified that it will outsource thefollowing software components to CloudTrack: preprocess, align files, deconvolution, substraction,storing reference files, and storing detection results. It has further found that it needs a PaaS fromCloudTrack for the customized software components preprocess and align files, whereas thestandard computing components deconvolution and substraction need SaaS. The components relatedto storage such as storing reference files and storing detection results require IaaS.

6.4. Identifying contextual properties

The architectural elements of the detection of heterozygous indel are now mounted on a cloud-basedenvironment as shown in Figure 8. AnalyzerPro plans to use the following ‘pay-as-you-go’ cloudservice models with CloudTrack.

• PaaS for the customizing file preprocessing and alignments. AnalyzerPro plans to extend theexisting capabilities of its preprocess and file alignment software components to handle variousfile formats. CloudTrack provides AnalyzerPro with the IBM System z10 machines and Linuxoperating platform along with the IBM Rational Development tools including Java compilerand debugging tools, all located in Irvine, USA. AnalyzerPro redevelops and deploys thecustomized software called iFiling using IBM Rational development tools. The software containstwo components: iPreprocess, and iAlign. These are owned and controlled by AnalyzerPro. The

Identify candidate services

Selectcloud service

model

Identify residence services

Find service

dependency

- Pre process- Align files- Deconvolution- Subtraction - Storing reference files- Storing detection results

PaaS:- Pre process- Align files

SaaS:- Deconvolution- Subtraction

IaaS:- Storing reference files- Storing detection results

- Load sample DNA- Get reference DNA

Two dependencies:1. Get reference DNA component is dependent on Storing reference files. It needs reference DNA sequences from the storage in CloudTrack 2.The services provided by CloudTrack is dependent on the residence compoent 'Get reference DNA'.

Figure 7. Results of applying the migration process framework.


Figure 8. AnalyzerPro uses various cloud service models with CloudTrack.


output of these components aligned files (data) are fed to the application software xMaths runningon the cloud (a SaaS). (Figure 8)

Table II summarizes the scope, ownership, and control distribution of the architectural elements(infrastructure, software) along with the stages (on-premise and off-premise) in PaaS. The table showssome interesting properties of PaaS in this example. The customized software iFiling (developed byAnalyzerPro) is located in CloudTrack (scope), but it is owned and controlled by AnalyzerPro in theoff-premise stage (see row 3). Similarly, the data (processed files and aligned files) are owned andcontrolled by AnalyzerPro but located in CloudTrack. Another piece of data (DNA files) is locatedin two different boundaries in two different stages of the service (row 1 on-premise and row 2 off-premise). The DNA files are within the boundary of AnalyzerPro (on-premise stage) before processedby the software iFiling (off-premise). These are in the perimeter of CloudTrack whereas processed(off-premise) by iFiling.Notice that the control over DNA files remains with AnalyzerPro, althoughthe scope has changed to CloudTrack as data moves from on-premise to off-premise. DNA files arepreprocessed and aligned by the software iFiling owned and controlled by AnalyzerPro.

Table II. Contextual properties of architectural elements in platform as a service.


1 DNA files AnalyzerPro AnalyzerPro AnalyzerPro On2 DNA files CloudTrack AnalyzerPro AnalyzerPro Off3 iFiling CloudTrack AnalyzerPro AnalyzerPro Off4 iPreprocess CloudTrack AnalyzerPro AnalyzerPro Off5 iAlign CloudTrack AnalyzerPro AnalyzerPro Off6 IBM Rational tool CloudTrack CloudTrack CloudTrack Off7 Java compiler CloudTrack CloudTrack CloudTrack Off8 Linux operating system CloudTrack CloudTrack CloudTrack Off9 Processed files CloudTrack AnalyzerPro AnalyzerPro Off10 Aligned files CloudTrack AnalyzerPro AnalyzerPro Off



• SaaS for the deconvolution and subtraction operations. According to the service levelagreements, CloudTrack provides IBM System z10 computers, xMaths software, and the Linuxoperating platform for the operations, all are located in Naples, Italy. AnalyzerPro will only supplypreprocessed and aligned files of DNA sequences for the operations. The input data are fed by thecustomized software iFiling (developed on the PaaS) to xMaths. Table III summarizes the scope,ownership, and control distribution of the architectural components (hardware, software).

Notice the first row in the table. AnalyzerPro owns the aligned files, but these are controlled byCloudTrack. CloudTrack gets the control over these objects when these are processed by its machinesand software within its boundary. AnalyzerPro does not have much control over any componentsincluding its data while on the cloud. It only owns data but does not have any control over them(see rows 1, 7, 8, and 9).

• IaaS for the storing DNA sequence files. AnalyzerPro also uses huge data storage capacity such asIBM ServerRAID M5000 series and IBM System Storage DS8000 provided by CloudTrack inorder to store its files that are processed and archived by the software xMaths (SaaS) ofCloudTrack. These are located in Suzhou, China. The IaaS also comes with the database softwareDB2 Image Extender along with the query processor QBIC. Table IV summarizes the scope,ownership, and control distribution of the architectural components (hardware, software) in IaaS.The table shows that AnalyzerPro owns the reference DNA files and detection results (data) andcontrol them; although these are stored in the boundary (scope) of the provider. In IaaS, morecontrol over data and processes are held by the consumer AnalyzePro. Although devices are inthe scope of and owned by the cloud provider, the consumer controls them (rows 3, 4, 5, and6). The table also shows and interesting fact that whatever AnalyzePro owns, the control isreturned to it in IaaS.

Table III. Contextual properties of architectural elements in software as a service.


1 Aligned files CloudTrack AnalyzerPro CloudTrack Off2 xMaths software CloudTrack CloudTrack CloudTrack Off3 Deconvolution CloudTrack CloudTrack CloudTrack Off4 Subtraction CloudTrack CloudTrack CloudTrack Off5 Linux operating system CloudTrack CloudTrack CloudTrack Off6 IBM System z10 CloudTrack CloudTrack CloudTrack Off7 Deconvoluted data CloudTrack AnalyzerPro CloudTrack Off8 Reference DNA files CloudTrack AnalyzerPro CloudTrack Off9 Detection results CloudTrack AnalyzerPro CloudTrack Off

Table IV. Contextual properties of architectural elements in infrastructure as a service.


1 Storing reference files CloudTrack AnalyzerPro AnalyzerPro Off2 Storing detection results CloudTrack AnalyzerPro AnalyzerPro Off3 DB2 Image Extender CloudTrack CloudTrack AnalyzerPro Off4 QBIC query processor CloudTrack CloudTrack AnalyzerPro Off5 IBM ServerRAID M series CloudTrack CloudTrack AnalyzerPro Off6 IBM System DS8000 CloudTrack CloudTrack AnalyzerPro Off7 Deconvoluted data CloudTrack Analyzerpro AnalyzerPro Off8 Reference DNA files CloudTrack AnalyzerPro AnalyzerPro Off9 Detection results CloudTrack AnalyzerPro AnalyzerPro Off



7. DISCUSSION

All key architectural elements belonging to the systems architecture of AnalyzerPro are laterdistributed across various sites as a result of the outsourcing to cloud computing. Most of these nowbelong to cloud computing except the data (DNA sequence files) and the customized software(preprocessor and file alignment) developed by AnalyzerPro on PaaS. Further details reveal thatdifferent processes, storage, and hardware devices used in cloud services are distributed at variouslocations (Figure 8). The PaaS is provided by the Irvine (USA) cloud location of CloudTrack, thedeconvolution and subtraction operations in SaaS are served by the software running on computerslocated in Naples (Italy), and the DNA sequence files are stored in disks located in Suzhou (China).Without the contextual properties along with the entire cloud-based software architecture, AnalyzerPromay not be aware of these various servicing locations unless explicitly informed by CloudTrack.

This study demonstrates that with the contextual properties, cloud consumers could clearly identifywhich architectural elements they own and which they do not. Although ownership is alwaysassociated with control, this is not always the case as we have seen in the example. It is clear that ina cloud-enabled environment, consumers give up much of their control over their data and processesbecause of the changing contextual properties in a cloud-based architecture. Once the consumer'sdata leave the organizational boundary, control is held by the cloud service provider in most cases.In our example, because AnalyzerPro has decided to consign all DNA sequence files to CloudTrack,it does not have much control over the processes and data while these are processed by CloudTrack.AnalyzerPro has lost control over majority of its architectural elements that are being designed,developed, owned, and managed by CloudTrack.

These changes have also other implications. The cloud consumer also loses flexibility regarding theextension or modification of processes as its control diminishes. In the example, AnalyzerPro has lostsome of its flexibility on the processing of DNA sequence. It now heavily depends on CloudTrack todo the deconvolution and subtraction operations. Another concern resulted in from the diminishingcontrol, ownership, and scope is the security and privacy. AnalyzerPro may have valid reasons toworry about the confidentiality and privacy of their DNA sequence files stored in devices owned andmanaged by CloudTrack because the DNA files are persistently stored in the databases and storagesowned by CloudTrack. Not only that, the services are located in various countries. The consumer doesnot know whether the transborder data movement among cooperating service providers is supportive toregulatory compliance because data located in different countries may be governed by different jurisdictions.

However, with the mapping of the architectural elements on the cloud-based architecture along withthe contextual properties, the cloud consumer could find more about their degree of control over thearchitectural elements, the ownership along with the responsibilities, and the architectural scope.These would enable them to plan their resources, design software architecture addressing theirbusiness needs, and monitor the usefulness of the cloud-based architecture. Despite somelimitations, this study is expected to bring the following benefits to cloud computing stakeholders:

1. Efficient computing resource distribution: Consumers of cloud computing can clearly see whicharchitectural elements belong to them and which are to cloud providers. This will help them toplan the distribution of their computing resources and the workload efficiently to its personnel.The allocation of systems architecture related resources could be planned in a more optimal way.

2. Better agreements and metering: Service level agreements could include unambiguous informationabout the ownership of specific architectural elements. On the basis of a clear mapping of architecturalelements and their control flows among stakeholders, metering could be carried out more accurately.The precise demarcation of responsibility could be defined on the basis of the identified contextualproperties of systems architecture mapped onto the cloud-enabled architecture.

3. Effective maintenance and management of systems: A better understanding about the contextualproperties of systems architecture would help cloud consumers to make right queries to cloudproviders about the desired behaviors of the services. The consumer would be in much betterposition to know which functionality they could customize and which functionalities could beextended by whom (consumer or cloud provider) in order to add more capabilities. Hence, softwaremaintenance and evolution of systems architecture could be well managed and synchronized.



4. Interoperability of security policies: The identified contextual properties could provide enoughinformation to the consumer to define their own security and privacy policy around variousarchitectural components. The privacy and data anonymization are major concerns of organizationsas reported. Several optimal solutions to the problem have been reported such as the studies ofZhang et al. (2012) and Zhang et al. (2013) [23, 24]. The consumer could find it much easier to de-cide where they need to enforce their own security shield. They can also know which architecturalelements are under the cover of the provider's security policy. This would help stakeholder toachieve an optimal interoperability of their security policies across their organizational boundaries.

As Grady Booch [22] rightly states in a different context that an architecture is a declaration of ashared reality that represents a common vision among a set of stakeholders and represented by a setof interlocking models. This also fits with cloud-based architecture where both the consumer and thecloud provider share their understanding of the system in interlocking artifacts. Systems architectureassociated with the contextual properties could enhance the interlocking and advance theunderstanding of the artifacts.

8. CONCLUSION

This study clearly suggests that the service migration process requires the contextual properties ofsystems architecture to be identified in terms of its key architectural elements, their interactions,control flow, ownership of elements, topological distribution of elements, and physical distributionof architectural elements. The contextual properties of systems architecture with clear control flowprovide everyone in the organization with an understanding of the impact of service outsourcing tocloud computing. The proposed approach raises the need for a new way of thinking regarding otherproperties of systems architecture. This paper is expected to advance our understanding of softwarearchitecture in a cloud computing context. The resulting improved understanding of contextualproperties of software architecture has important and strategic implications for enterprises. Thisimproved understanding can strongly benefit the executives of enterprises by providing anexplanation of some other issues that they should consider before making a decision regardingmigrating services to cloud.

Transplanting a traditional systems architecture onto a cloud platform without right contextualproperties would mean trying to fit a square object into a round hole. A balanced need is to be struck indeveloping architectures that can be used to provide enough technical information as well as contextualproperties to all stakeholders. This study requires further investigations on the role of contextualproperties and exploration on how to measure the impact of these properties on systems architecture. Itincludes formulating methods that could reason about the presence or absence of these properties insoftware architecture and their impact on business processes. We acknowledge that this topic requires amore deeper analysis in order to flesh out a complete taxonomy of cloud-enabled software architectureand the associated contextual properties.

ACKNOWLEDGEMENTS

This paper is an extended version of the work published in the Ninth IEEE International Conference onDependable, Autonomic and Secure Computing. This publication was made possible by the support of aNational Priorities Research Program grant from the Qatar National Research Fund. The statements madeherein are solely the responsibility of the authors.

REFERENCES

1. Shaw M, Garlan D. Software Architecture: Perspectives on Emerging Discipline. Prentice-Hall, Upper Saddle River,NJ, 1996.

2. Bass L, Clements P, Kazman R. Software Architcture in Practice. Addison-Wesley, Upper Saddle River, NJ, 2003.3. Perry D, Wolf A. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes

1992; 17(4):40–52.4. Fielding R, Taylor R. Principled design of the modern Web architecture. ACM Transactions on Internet Technology

2002; 2(2):115–150.



5. Wang H, He W, Wang F. Enterprise Cloud Service Architectures. Information Technology Management, Springer,2012; vol. 13(3):445–454.

6. Khalidi Y. Building a cloud computing platform for new possibilities. IEEE Computer 2011; 44(3):29–34.7. Tsai W, Sun X, Balasooriya J. Service-oriented cloud computing architecture. Proc. of the IEEE 7th Int'l conference

on Information Technology 2010; 684–689.8. Koziolek H. The SPOSAD architectural style for multi-tenant software applications. Proceedings of the Ninth

Working IEEE/IFIP Conference on Software Architecture 2011; 320–327.9. Mesbah A, van Deursen A. A component and push based architectural style for AJAX applications. Journal of

System and Software 2008; 81(12):2194–2209.10. Papazoglou M, Andrikopoulos V, Benbernou S. Managing evolving services. IEEE Software 2011; 28(3):49–55.11. Zhang Q, Cheng L, Boutaba R. Cloud computing: state-of-the-art and research challenges. Journal of Internet

Services and Applications, Springer 2010; 1(1):718.12. Samimi F, McKinley P, Sadjadi S, Tang C, Shapiro J, Zhou Z. Service clouds: distributed infrastructure for adaptive

communication services. IEEE Transactions on Network and Service Management 2007; 4(2):84–95.13. Zhang L, Zhou Q. CCOA: cloud computing open architecture. Proceedings of the IEEE International Conference on

Web Services 2009; 607–616.14. Banarjee P, et al. Everything as a service: powering the new information economy. IEEE Computer 2011; 44(3):36–43.15. Tang L, Dong J, Zhao Y, Zhang L. Enterprise cloud service architecture. Proceedings of the IEEE 3rd International

Conference on Cloud Computing, Miami, 2010; 27–34.16. Armour F, Kaisler S, Liu S. A big picture look at enterprise architectures. IEEE IT Professional 1999; 1(1):35–4217. Armour F, Kaisler S. Enterprise architecture: agile transition and implementation. IEEE IT Professional, 2001; 30–37.18. Milojicic D, Douglas F, Paindaveine Y, Wheeler R, Zhou S. Process migration. ACM Surveys (n.d.) 32(3):241–299.19. Kaisler S, Money W. Service migration in a cloud architecture. Proceedings of the 44th Hawaii International

Conference on System Sciences 2011; 1–10.20. Desisto R, Plummer D, Smith D. Tutorial for understanding the relationship between cloud computing and SaaS.

Gartner, G00156152, 2008.21. Khan K, Gangavarapu N. Addressing cloud computing in enterprise architecture. Cutter IT Journal, Cutter

Consortium, MA, 2009; 22(11):27–3322. Booch G. Architecture as a shared hallucination. IEEE Software 2010; 27(1):95–96.23. Zhang X, Liu C, Nepal S, Pandey S, Chen J. A privacy leakage upper-bound constraint based approach for cost-effective

privacy preserving of intermediate datasets in cloud, IEEE Transactions on Parallel and Distributed Systems, to appear,accepted on 23 July 2012, http://doi.ieeecomputersociety.org/10.1109/TPDS.2012.238.

24. Zhang X, Yang T, Liu C, Chen J. A scalable two-phase top-down specialization approach for data anonymization usingMapReduce on cloud, IEEE Transactions on Parallel and Distributed Systems, in press, accepted on 6 Feb. 2013.


http://doi.ieeecomputersociety.org/10.1109/TPDS.2012.238

Documents

Role of contextual properties in enterprise service migration to cloud computing