A Pattern-Based Approach to Cloud Transformation

2011 IEEE 4th International Conference on Cloud Computing A Pattern-Based Approach to Cloud Transformation Yi-Min Chee, Nianjun Zhou, Fan Jing Meng, Saeed Bagheri Peide Zhong School of Computing, Informatics, and Decision Systems Engineering Arizona State University Tempe, AZ 85287, USA Peide.Zhong@asu.edu IBM T.J. Watson Research Center Hawthorne, NY 10532, USA {ymchee, jzhou, sbagher}@us.ibm.com mengfj@cn.ibm.com based business models, and self-service provisioning), as well as to address concerns that are highlighted by the move to the cloud (e.g. security and privacy), and to enable SaaS and BPaaS models which offer functionality as a service. Transformation needs will vary depending upon the application and intended target, and so the solution to the problem of transforming a particular application will always be unique in some aspects. Fortunately, although it is not possible to formulate a single solution that answers all transformation problems, it is still possible to develop one general model to help users to make decisions when they decide to transform their applications. In order to address these transformation needs, one essential asset is a set of proven best practices expressed as enablement patterns. Design patterns [3] are well known in the literature and have been widely applied in the context of software architecture, design, and engineering. In the space of cloud computing, patterns have been applied to the problems of architecture and design for cloud computing infrastructure [4], as well as to the space of application design for specific cloud platforms [5, 6]. Given the breadth of functionality and capabilities provided by cloud computing platforms, we expect new patterns for cloud computing adoption to be discovered and documented with increasing frequency, ranging from high-level and platform independent patterns to very specific patterns that invoke or rely upon specific features of a platform or set of tools. Enablement patterns can help to reduce the uncertainty and risk associated with transformation, as well as cutting down on the time required for the actual transformation work (either by outlining the set of steps to be carried out or through the use of tools that automate the application of patterns). However, as with any other asset, the value of patterns depends on the ability of a user to identify and select relevant patterns for their given situation. In order to address this problem, prior research has focused on developing more formal representations and classifications for design patterns [7], which help to organize a collection of patterns in such a way as to make it easier to identify relevant patterns to address a given problem. These classifications typically associate metadata such as keywords, to individual patterns. In addition, they may organize patterns using relationships to suggest patterns which can be leveraged together. But even after narrowing by such classification, the architect may be left with a large number of possible patterns to consider. Abstract— With the growing interest in cloud computing, more and more businesses are looking not only to migrate their applications to the cloud but also to transform them to better leverage capabilities that are provided by cloud platforms or to enable new business models that are facilitated by the cloud. One problem clients face in this area is a lack of experience and knowledge as to how best to accomplish this transformation. We propose a Cloud Transformation Advisor (CTA) which helps users to select appropriate enablement patterns from a knowledge base of best practices when performing transformation planning. This knowledge base uses a structured representation to capture application information, cloud platform capability information, and enablement pattern information in order to facilitate pattern selection. We describe this representation and a mathematical model which leverages it to choose the "best" combination of patterns for a given transformation problem. We present an example which illustrates the approach, and describe the usage of the CTA. Keywords- patterns; cloud computing; transformation; advisor I. INTRODUCTION Cloud Computing brings new opportunities for businesses, including greater flexibility in terms of cost due to a pay-as-you-go model [1], elasticity to respond to changing demand, the potential to offer internal applications to others as a service without having to worry about managing the infrastructure, and new business models for solution offerings. As a result, many enterprises are looking at the cloud not only as a target for new development, but also to extract additional value from their existing solutions and applications which have been developed for and deployed on traditional computing platforms. Cloud platform providers provide automation to ease the transition cost and effort required to move applications onto their platforms. Cloud migration tools, which extend capabilities first introduced for virtualization, allow many simple applications to be run on the cloud without requiring code changes (e.g. SharePoint Cloud Migration Tool [2]). However, in order to truly realize the benefits made possible by the cloud, many existing applications or solutions will need to be transformed both to take advantage of specific capabilities provided by the target cloud platform (such as multi-tenancy support, metering & billing to enable usage978-0-7695-4460-1/11 $26.00 © 2011 IEEE DOI 10.1109/CLOUD.2011.86 388 including technical information, business information, and project information. Technical information, as defined by the application profile, includes such things as the current application platform, operating system, architectural information, implementation details such as programming languages and technologies used for data storage, presentation, and integration. This information is what the architect or transformation specialist needs to know about the as-is state of the application in order to make decisions about transforming the application to the desired to-be state. Business information is also relevant to transformation, in that companies from the same industry, or those with similar objectives, business models, or delivery models, may have similar requirements for transformation. Finally, since every transformation project happens in the context of real-world project constraints, such as budget, expected delivery time, transformation risk, expected revenue per tenant per year and initial investment, we also capture this information. In our model, we represent the Application Profile information using features, such that an application can be viewed according to the set of features it relies upon or provides. When confronted with many alternative patterns, determining which one is best suited to the application at hand is a key challenge for successful transformation. This problem is exacerbated when the architect must consider many transformation requirements at the same time, resulting in the need to apply multiple patterns. The optimal solution considering each choice in isolation may not be feasible if, for example, the best choice pattern for one requirement has conflicting dependencies with the best choice for another requirement. To address this complexity, we need a way to consider multiple problems and solutions in a holistic manner--this requires a more structured representation that can be leveraged in analyzing requirements against a set of patterns. In this paper, we propose an enablement pattern representation to assist architects and developers in selecting patterns for transforming a particular application. Based on this model, we formulate a mathematical description for the problem of selecting the “best” set of candidate enablement patterns, and describe solutions using well-known optimization techniques. We present a case study to illustrate the approach. Finally, we discuss how the model & solution can be used in the context of a transformation advisor tool. II. CONTENT TAXONOMY IN CTA B. Cloud Platform Capability Information Cloud platform capability information is used to describe the features that are supported by a particular cloud platform in order to select the most appropriate platform to target for a transformation. It can be illustrated as shown in Figure 2. Although there have been several attempts to describe and enumerate the characteristics that embody the cloud [8, 9], there is at present no standard which describes the capabilities of the cloud. Not all cloud platforms support the same set of capabilities, and so depending upon the goals of the transformation or the requirements of a particular enablement pattern, one specific platform may be a better choice than another. Cloud platform capability information captures the differences between various cloud platforms in terms of the features they support. In determining the best course of transformation, we consider three types of information: the application profile, cloud platform capabilities, and enablement patterns. These three types of information intersect to form a general transformation template which is then used to enable the selection of enablement patterns for a given transformation problem. A. Application Profile Information Application Profile information is the first factor that needs to be considered in the context of cloud transformation. An illustration of this information is shown in Figure 1. The application profile captures all of the information about the application and its context which factors into the decision of how to transform the application for the cloud. This information can cover multiple points of view, Figure 1. Application Profile Information Figure 2. Cloud Platform Information 389 Figure 3. Transformation Enablement Pattern Information If we maintain these three mappings separately, we require updates to the other two models whenever one is updated. Instead, we consider the union--intersection of the three kinds of information in order to form the general transformation template to capture this intersection and not require a separate update of three mappings. General Transformation Template information links the triple of the application profile, cloud platform capability, and transformation enablement pattern to provide a transformation path from the as-is application to the to-be cloud capability enabled one. Figure 4 illustrates the union-intersection among the General Transformation Template and above mentioned three kinds of information. C. Transformation Enablement Pattern Information Transformation Enablement patterns can be seen as a form of design pattern, which captures best practice knowledge about how to enable a particular capability or functionality using an approach that has been well documented. Like a typical design pattern, an enablement pattern captures the steps required in order to apply it. In addition, the enablement pattern describes the problem it solves, any prerequisites for applying it, and other dependencies. Enablement patterns can be classified in different ways in order to help with selection/navigation--such classification is not the topic of this paper. Instead we focus here on the dependencies for an enablement pattern and the use of that information to facilitate optimal selection of a transformation solution. This dependency information, which we again capture as features, can come in several forms, including architectural prerequisites, platform, operating system, language, technology, as well as design. These extensions to the typical design pattern information allow the enablement patterns to be considered as part of an analysis to determine optimal transformation. Figure 3 shows an illustration of what is captured in the Transformation Enablement Pattern Information. Figure 4. Union--intersection of Application Profile, Cloud Platform Capability, and Enablement Pattern via General Transformation Template D. General Transformation Template Information In order to determine the technical fit of an enablement pattern for the solution of a transformation problem, we need to compare the enablement pattern's requirements against the current state of the application. This requires a mapping between the application profile information and the enablement pattern information. Similarly, in order to decide which cloud platform is a best fit for an application, we need to map between the application's profile information and the capabilities supported by the various cloud platforms. Finally, in order to determine which cloud platform is most suitable target for a set of enablement patterns, we must map between the needs of those patterns and the capabilities provided by the platforms. General Transformation Templates capture the cloud transformation best practices which are neutral to the cloud platform as well as the transformation enablement patterns. General Transformation Template specifies the two types of transformation best practices including the features required by the transformation and quality attributes achieved by the transformation. Figure 5 gives an illustration of General Transformation Template information. Features capture all the information related to the transformation functional requirements including the infrastructure, platform, middleware, architecture, programming language and etc. The features link to the technical information of the Application Profile information, Figure 5. General Transformation Template Information 390 After the “best” solution is selected, another problem is to choose the “best” cloud platform on which to deploy the solution. This means that given a set of enablement patterns which represent the selected transformation solution, and a set of cloud platforms, we wish to select the cloud platform which is the best match, feature-wise to the set enablement patterns. An alternative scenario corresponds to the case where the choice of a cloud platform is made in advance, whether for business or technical reasons. In this case the goal is to select the transformation alternative (set of enablement patterns) that best matches both the application profile information and the cloud platform information of the selected target. Figure 6 depicts an example of a transformation problem instance with three requirements (r1, r2, and r3), which need to be addressed in the transformed solution. A set of three enablement patterns {p1,1, p1,2, p1,3} addresses requirement r1, a set {p2,1, p2,2,} addresses requirement r2, and {p3,1} addresses requirement r3. cloud capabilities of the Cloud Platform Capability information, and dependencies of the Cloud Enablement Pattern information. Thus, the triple of Application Profile, Cloud Platform Capabilities, and Enablement Patterns are interconnected by the General Transformation Template from the functional perspective. Quality Attributes specify the runtime and non-runtime quality estimation of the transformation. Customers specify the expected transformation quality requirements in the application profile. Meanwhile, the quality attributes supported by the cloud platform and enabled by the enablement patterns have been specified in the knowledge base. Therefore, the triple of Application Profile, Cloud Platform Capabilities, and Enablement Patterns are interconnected by the General Transformation Template from the non-functional perspective. With the four kinds of information, candidate transformation solutions can be generated automatically by searching an available path from the transformation requirements in the weighted directed transformation graph composing by the Application Profile information, Cloud Platform information, Transformation Enablement Pattern information, and General Transformation Template information. III. CLOUD TRANSFORMATION Having described the structure of the Application Profile Information, Enablement Pattern Information, Cloud Platform Information, and the General Transformation Template, we now show how these structures are used to formulate an instance of a cloud transformation problem, given the application profile information for the application to be transformed, a knowledge base which contains the set of all known enablement patterns, and cloud platform information for each potential target cloud platform on which the solution could be deployed. Our first goal is to find the “best” set of enablement patterns which fulfill a set of transformation requirements which can either be specified as part of the application profile information, or as a separate list. We assume that each transformation requirement can be satisfied by some subset of enablement patterns within the knowledge base. This is shown in Figure 6. Since a particular application will have multiple requirements that must be addressed, the overall transformation solution will consist of a set of enablement patterns which collectively address the complete transformation requirements of the application. We define the “best” enablement pattern as the one that is the closest match, feature-wise, to the application profile of the application to be transformed. Given this definition, a transformation solution could be generated by simply choosing the “best” pattern from among the subset of relevant patterns that addresses each transformation requirement. However, in practice it is also necessary to consider the compatibility of enablement patterns with one another, so we must account for the matching between enablement patterns within a solution alternative as well. Figure 6. Enablement Pattern Knowledge Base We can then create a feasible transformation solution by selecting one enablement pattern from each of the three sets. For the example shown in Figure 7, the possible solutions are (p1,1, p2,1, p3,1), (p1,1, p2,2, p3,1), (p1,2, p2,1, p3,1), (p1,2, p2,2, p3,1), (p1,3, p2,1, p3,1) and (p1,3, p2,2, p3,1). Figure 7. A Transformation Problem Instance More precisely, in the case where we have l requirements, let us denote ni as the number of enablement patterns which address the ith requirement. A feasible solution will be a 391 combination of enablement patterns created by selecting one pattern from each requirement’s pattern set. Let us use S to denote the set of all feasible solutions. Then, the total number of feasible solutions (cardinality) N(S) will be: l (1) N ( S ) = ∏ ni i =1 From (1), we know that the feasible solution is l l §n· (2) N ( S ) = ∏ ni ≤ ¨ ¸ ©l¹ i =1 Here, n is the total number of enablement pattern. Figure 8. Enablement Pattern and Application Profile Feature Mapping A. Mathematical Definitions Our goal is to select the most suitable cloud platform from the candidate platforms for a given business application. We consider each cloud platform from both migration and cost perspectives. In the following, we formulate two separate optimization problems to address this. We achieve the final selection through two steps. The first step is, for a given cloud platform, to find the best set of enablement patterns to transform the application. Then, we select the most suitable cloud platform based on the results of the first step. Again, let us assume that there are l requirements for a cloud solution, denoted as R       . We denote E  conflicts between the features required by a set of enablement patterns and the features utilized by the application that is to be transformed. X How do we calculate the coverage transformation F   solution   F U X C X    for a given  ? Let  denote the set of all existing features. X  ! !  !U to represent whether a  F LZE"#N#ELEEERN $ . !$    ERE  is a variable to The coverage function can then be defined as: indicate whether the j enablement pattern is selected for U    ELEE .    ERE  C X  !$ (3) $  Let U  dimensional matrix H be used to define the relationship of the enablement patterns and the existing features, such that We use   dimensional matrix G to define the relationship of the enablement patterns and the requirements, where    R I TH REREEN   .  ERE  HI  The matrix is built based on the engineering knowledge shown in Figure 8. The number of elements in this matrix    NEE I TH ERE   "LNENLZE   ERE  This matrix is defined to quantify the potential conflict of applying a pattern to the application requiring transformation. There are four possible scenarios for a given pattern and a particular feature: • The pattern doesn't require the feature, but the application doesn't contain this feature; • The pattern doesn't require the feature, but the application contains this feature; • The pattern requires this feature, and also the application contains the feature; l which have the value one should be equal to (2) given feature in the application is utilized in the selected enablement patterns array for solution X , i.e., th I  F We use array Z  this paper, we assume that each enablement pattern only satisfies one business requirement. We use array X     (selected enablement patterns) to the solution, i.e.,  RG N C X X as the set of all enablement patterns- E    . In represent a feasible solution, where  ¦ n , the total i i =1 number of the patterns (assuming that each pattern only enables one requirement). B. Optimization From a Migration Perspective Given the above mathematical definitions, we now describe the problem of finding an optimal solution as an integer programming problem to minimize the number of 392 • The pattern requires this feature, but the application doesn't contain this feature. We see that a conflict only happens for the 4th scenario. For example, if the pattern relies on having a database that supports row-level access control (feature), and the application doesn't use a database that supports row-level access control, then there is a conflict. Before we can apply this pattern, the application would have to be further modified to use a supported database. Given this, the element value of Z X can be found as:     H $  !$      ERE   U IV. $  (4) H$  $   Finally, the optimal transformation solution for least migration effort for a given cloud platform is given by: U X  X subject to:   RG N H$  $  (5)   I    I    %  & ReqID r1 % & r2 This is an integer programming problem. The first constraint ensures that each requirement in R       is satisfied only one enablement pattern. r3 r4 From (1), we know that the number of feasible solutions is a polynomial function of the number of patterns (n). In the case of having limited numbers of patterns (n), we can exhaustively search all the feasible solutions and find out the optimal solution. In the case where there are too many patterns, and we wish to find a feasible solution very quickly, a heuristic algorithm such as a genetic algorithm can be used. r5  RG N P X  RG N X subject to: X C CASE STUDY Requirement description Content submitted by each participant should be vetted prior to being made available for sharing Each tenant wants a different look-and-feel (e.g. different logo, style, and etc.) Tenants want a metering capability to capture their resource consumption. Tenant-specific authentication and authorization must be enabled. IT department wants the application to scale automatically to accommodate new tenants. For example, requirement r1 (which the participants in the joint venture have agreed upon) is the necessity to have the content submitted by each participant vetted prior to being made available for sharing. In order to accomplish this, the venture will enlist the services of multiple providers to do the vetting. Depending on the participating tenant, different vetting services are to be invoked through web service invocations that take a content submission and return the results of the vetting process. This requirement can be summarized as one where we wish to enable multi-tenant tenant-specific service invocation. Given the requirement r1, two patterns e11, e12 from our example knowledge base are filtered out as showed in Table 2. Pattern e11 uses the mediation capabilities of an Enterprise Service Bus to route a request (in this case a vetting request) to a service provider based on the id of the tenant (participant). Pattern e12 uses the dynamic routing & assembly functionality of the IBM WebSphere Business   %  & Table 1. SmartCM cloud transformation requirement set R C. Optimization From a Cost Perspective Another important factor is the cost of implementing of an application on a given cloud platform. We will demonstrate that the problem is an integer linear programming problem which can be solved by one of the traditional optimization algorithms. We assume that each enablement pattern has a fixed price, denoted as cj for the jth pattern. An optimal solution is then given by: X  As an example, consider the case of a content management application, SmartCM, which we wish to transform for the cloud. The goal of the project is to allow the SmartCM application, which was originally developed for internal use, to be deployed in a cloud environment where multiple participants in a joint venture can share their content in the context of a collaboration on which they are working. The application must be transformed to enable a multi-tenant Software-as-a-Service model where tenants (the participants) can be added and removed over time, and individual users from the participants are granted access based on assigned roles. There are many requirements for the transformation project, which range from security issues that must be addressed, to data locality requirements. The detailed SmartCM cloud transformation requirements are documented in Table 1.  U !$  %  & which is an integer linear programming problem. The reason for choosing the linear pricing scheme is that we assume the operational cost for a particular enablement pattern on a given cloud platform is fixed. Using the step function notation, we have: C X  I (6)   393 into the ILOG CPLEX solver and obtain the final optimal solution illustrated in Table 4. Services Fabric product to accomplish the same objective. Each pattern is represented in the knowledge base in terms of the set of activities, roles, and skills required to apply the pattern, as well as the set of dependencies, which are prerequisites to the usage of the pattern. ID e11 Enabled ReqID r1 e12 r1 Enablement pattern description Multi-tenant tenant-specific service invocation using ESB Mediation Multi-tenant tenant-specific service invocation using dynamic assembly ReqID r1 Selected PatternID e11 Required featureID r2 e23 f1, f2, f3, f4 r3 e31 r4 e42 r5 e53 f4, f5, f6 Table 2. Enablement pattern set E1 that enables the Requirement r1 Further, the features required by the enable pattern set E1 are identified from the example knowledge base as listed in Table 3. In this case, Pattern e11 requires features f1, f2, f3, f4, while Pattern e12 requires features f4, f5, f6. FeatureID f1 f2 f3 f4 f5 f6 Pattern Description Multi-tenant tenant-specific service innovation using ESB Mediation Multi-tenant UI isolation using WebSphere Virtual Portal Server and Tivoli Access Manager Multi-tenant metering and billing supported by Tivoli Usage and Account Manager Building the multi-tenant user registry and access control in a SaaS application using WebSphere Portal Server and Tivoli Directory Server Automatic extension of dynamic cluster by using WebSphere Virtual Enterprise Server (WVES) Table 4. Optimal SmartCM cloud transformation solution This SmartCM cloud transformation case study illustrates how the content taxonomies and mathematical model are used in cloud solution transformation and validates the applicability of our model. Feature description WebSphere Enterprise Service Bus WebSphere Service Registry & Repository Tivoli Access Manager WebSphere Portal Server WebSphere Business Service Fabric Server Tivoli Directory Server V. A CLOUD TRANSFORMATION ADVISOR TOOL In this section we briefly describe a Cloud Transformation Advisor tool that leverages the representation and formulation described above. The advisor tool is used by an architect or consultant to assist with the determination of how best to transform an application. In the Cloud Transformation Advisor, an extensible knowledge base captures information about known enablement patterns and cloud platforms, corresponding to the enablement pattern and cloud capability information described above. The advisor tool guides the user through a phased evaluation approach, which includes the steps of 1) identifying required capabilities, 2) generating and evaluating transformation alternatives, and 3) making a selection. In the initial data collection phase of the advisor, the user enters as input the application profile information, which provides feature information used in the selection of patterns. In the next step, the advisor elicits the cloud capabilities that are desired in the transformation in order to identify the requirements of the transformation problem. For a given problem, there may be many requirements, and for each requirement, the knowledge base may contain several alternative patterns, resulting in the complexity that requires the mathematical approach defined in the preceding sections. Based on the set of requirements, the Advisor then generates a set of candidate solutions by considering the enablement patterns that address these requirements. The alternatives are presented to the user with the ability to view detailed information for each one. Based on the detailed information, the user selects a transformation solution from among the alternatives, and the advisor generates a report detailing the required transformation activities and other aspects such as estimates of the effort required. Table 3. The feature set F1 required by enablement pattern set E1 In addition to the requirements of the SmartCM application, which we’ve already discussed, we also require its application profile information in order to apply the pattern selection approach. In this case we focus on the technical information about the application's current state, which is shown in Figure 9. From the figure, we can see that the application is currently implemented as a web application, which already leverages the IBM WebSphere ESB product (f1), the IBM WebSphere Service Registry and Repository (f2), WebSphere Process Server, and WebSphere Portal Server (f4). Figure 9. Application Information for SmartCM For each requirement ri, the relative enablement pattern set Ei and feature set Fi can be constructed from the example knowledge base following the illustrative approach as requirement ri. With the data set constructed above, we apply the equation 5 detailed in the previous section to compose the mathematical optimization model. Then we input the model 394 VI. captured in a highly structured manner, and so harvesting of content is also a challenge. Possible areas to address include tools for extraction of information from unstructured documents, mechanisms to avoid duplication of features in the knowledge base, and procedures for validating content. Once the advisor tool is in use, additional opportunities to assist the user can be enabled by tracking usage of the tool. These include the use of collaborative filtering techniques to augment the advisor’s recommendations, determination of content quality, and identification of areas of need in terms of harvesting additional content. Finally, we believe that the model and tool described here can be applied to additional areas. One possible example is to support portability between clouds, by capturing information (enablement patterns) that describes how to move applications between cloud platforms. RELATED WORK In [10], Zdun and Avgeriou describe a systematic approach for the modeling of architectural design patterns through the use of architectural primitives. Like our enablement pattern modeling, they advocate a more structured representation for describing their architectural patterns in order to address issues of expressiveness and variability. Kamal and Avgeriou [11] extend this with a focus on enriching the capturing semantics around the behavior of a pattern. Building on the work in [10], Zdun, et.al. [12] describe an architecting process that is based on pattern selection, which is also supported by a set of tools. In their work, the focus is more on documenting the architectural decisions that are made rather on providing assistance to guide the selection of patterns. With respect to evaluation of patterns, Petter, et.al. [13] have proposed a framework for pattern evaluation based on design science, which includes a set of criteria to be used. As opposed to our evaluation process, however, which is leveraged to select patterns for usage, their framework is oriented instead towards evaluating patterns in order to help with pattern lifecycle management. REFERENCES [1] [2] [3] VII. CONCLUSION AND FUTURE WORK [4] In this paper, we described a pattern-based approach to cloud transformation, which leverages a knowledge base of enablement patterns and cloud platform information, which is captured in a structured form. Based on this model, we presented a mathematical model to select an optimal solution for a given cloud transformation problem, based on feature information common to an application profile, a set of enablement patterns, and a set of cloud platforms. We then described a Cloud Transformation Advisor tool that uses this approach to assist an architect to solve a transformation problem. There are several extensions to the described work that we are interested in pursuing; they roughly fall into four categories: extensions to the mathematical model and its application in the advisor; infrastructure needed to make construction of the knowledge base possible for domain experts, extensions of the advisor tool itself, and consideration of other problem areas in which this could be applied. In the advisor analysis presented above, we use technical fitness, as described by feature compatibility, as the measure that is used to determine the optimal solution. In actual cases, the choice of whether to use one pattern or another is really determined by other aspects in addition to technical fitness— these can include quality, cost-benefit, risk and other factors. Our advisor takes those factors into account as well when evaluating transformation alternatives, but we would like to incorporate them into an overall mathematical framework for analysis. The mathematical framework and tool described above depend on the availability of enablement pattern content [5] [6] [7] [8] [9] [10] [11] [12] [13] 395 View publication stats Wikipedia. (2011). Software As a Service. Available: http://en.wikipedia.org/w/index.php?title=Software_as_a_service&ol did=412576788 Metalogix. Metalogix SharePoint Site Migration Manager 2010. Available: http://www.metalogix.net/Products/SharePoint-SiteMigration-Manager-2010/ E. Gamma, et al., Design patterns: elements of reusable objectoriented software vol. 206: Addison-wesley Reading, MA, 1995. Oracle. Cloud Computing Patterns, Architectures and Best Practices. Available: http://wikis.sun.com/display/cloud/Patterns Microsoft. Designing Services for Windows Azure. Available: http://msdn.microsoft.com/en-us/magazine/ee335719.aspx IBM. SaaS Enablement Blueprints. Available: ibm.com/isv/marketing/saas/demo_series.html P. Avgeriou and U. Zdun, Architectural Patterns Revisited - A Pattern Language, Proceedings of 10th European Conference on Pattern Languages of Programs (EuroPlop 2005), Irsee, Germany, pages 139, July, 2005. B. P. Rimal, E. Choi, and I. Lumb, A Taxonomy and Survey of Cloud Computing Systems, Proceedings of the 2009 5th International Joint Conference on INC, IMS and IDC, p. 44-51, August 25-27, 2009. L.Youseff, M. Butrico, and D. Da Silva, Toward a Unified Ontology of Cloud Computing, Grid Computing Environments Workshop, 2008, GCE’08 (2008), pp. 1-10. Uwe Zdun and Paris Avgeriou. 2005. Modeling architectural patterns using architectural primitives. In Proceedings of the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA '05). ACM, New York, NY, USA, 133-146. Ahmad Waqas Kamal and Paris Avgeriou. 2008. Modeling Architectural Patterns' Behavior Using Architectural Primitives. In Proceedings of the 2nd European conference on Software Architecture (ECSA '08), Ron Morrison, Dharini Balasubramaniam, and Katrina Falkner (Eds.). Springer-Verlag, Berlin, Heidelberg, 164179. Uwe Zdun, Paris Avgeriou, Carsten Hentrich, and Schahram Dustdar, Architecting as decision making with patterns and primitives, Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge (SHARK '08). ACM, New York, NY, USA, 2008, pp. 11-18. Stacie Petter, Deepak Khazanchi, and John D. Murphy. 2010. A design science based evaluation framework for patterns. SIGMIS Database 41, 3 (August 2010), 9-26.