Assess enterprise applications for cloud migration
Using the Analytic Hierarchy Process to evaluate apps for the cloud
Without a doubt cloud computing offers advantages for enterprise operations:
- It can help reduce costs (for instance, by setting up and configuring an application testbed or by being able to add and subtract computing power when you need it).
- It can help you process large data sets faster (by balancing workloads where and when needed).
- It can help your business respond more quickly to changing conditions (by being able to apply business analytics to larger amounts of mixed-structure data in a more rapid way).
But how do you know whether an enterprise application is suited for the cloud?
There are varied business, technology, and risk considerations which can have profound effect on the overall success of cloud initiatives in an enterprise, meaning there is no "one-size-fit-all" answer for whether an application "fits" in the cloud (which I will refer to as fitment). Each enterprise has to assess its application portfolio based on its own business imperatives, technology strategy, and risk appetite.
Some of the questions businesses need to ask themselves before undertaking cloud initiatives are:
- What factors should I consider for cloud enablement of my enterprise applications? How do I judge different competing priorities?
- How do I identify the applications and services that are best suited for moving to a cloud environment based on business priority and technical fitment?
- How do I prioritize enterprise applications and services for a "phase-smart" cloud enablement? How can I avoid that "gut feeling" and bring objectivity into the evaluation?
- What are the different risks involved?
With these questions in mind, I've developed an application portfolio assessment approach to determining the suitability of your enterprise applications for the cloud. It is based on the Analytic Hierarchy Process (AHP).
AHP is a structured technique for making complex decisions that helps users sort out the "best" decision for their challenge, situation, and variables instead of the finding the "correct" decision. It was first conceived in the 1970s. The process is straightforward:
- Decompose the problem into series of easier-to-understand sub-problems. Any and all input variables are welcome, whether they are precise data tables or rough guesses — as long as it applies to the situation at hand.
- Evaluate the elements by comparing them to each of the other elements, two elements at a time. You can do this using concrete facts or judgments — you are deciding each element's relative importance.
- Assign a numerical value to each of the evaluations, which allows you to compare each element to the others across the life cycle of the problem-solving process.
- Calculate numerical priorities for each of the decision alternatives; these represent each alternatives' perceived relative ability to achieve the decision goal.
In this article, I provide details about AHP and demonstrate how to apply this approach to support your decision on whether or not an enterprise application is appropriate for implementation in the cloud. And since all cloud systems perform under the same general concepts, this technique should be useful to you regardless of which cloud platform (or platforms) you choose to employ.
Figure 1 illustrates the assessment approach via a high-level flow chart.
Figure 1. Flow chart of application portfolio assessment for cloud
The approach is a multi-dimensional statistical evaluation; enterprise applications are evaluated in three dimensions:
- Business value: How much business value would the organization accrue by moving the applications to cloud?
- Technical fitment: How feasible is it to move the applications to cloud?
- Risk exposure: How much risk is involved in moving the applications to cloud?
Each of these dimensions has decisive effect on a go/no-go decision regarding cloud enablement of applications. For example, an application may be evaluated to have high scores in the business value and technical fitment dimensions, but it may not be a good candidate for cloud enablement if the risk exposure is higher than the level of risk a particular enterprise is willing to assume.
Evaluation of an application in each of these dimensions is a multi-criteria decision analysis (MCDA); AHP is one of the methods used in MCDA. (For more on MCDA, see Related topics.) AHP involves the evolution of different alternatives based of various criteria, some which may conflict with other alternatives, some which have a contrasting nature (be it qualitative or quantitative) or impact (positive or negative) on overall suitability.
The techniques used in the AHP quantify relative priority for a given set of criteria on a ratio scale. AHP offers advantages over many other MCDA methods:
- AHP provides a comprehensive structure to combine both quantitative and qualitative criteria in the decision-making process.
- AHP brings an ability to judge consistency in analysis process to the table: This helps reduce anomalies and heighten objectivity.
Another point worth noting is that at the beginning of the assessment, applications that obviously do not fit the profile are eliminated. Internal and external applications are segregated to be evaluated separately since they have concerns of varied nature and importance. Internal applications are those that are accessed only from within the firewall of an enterprise; external applications can be accessed from outside the firewall. As an example to show how each deserves different considerations, security concerns of external applications are much more stringent then internal applications.
Now let's use AHP to evaluate a set of applications for cloud suitability.
Evaluation using AHP
There are several components, or steps, involved in using AHP to evaluate the suitability of an application for the cloud. These include:
- Defining criteria hierarchy.
- Determining criteria priority.
- Comparing your application against the criteria.
- Calculate overall AHP score.
Define criteria hierarchy
Each of the multiple dimensions I introduced (business value, technical fitment, risk exposure) has a number of criteria; these in turn can further have multiple levels of granular sub-criteria (Figure 2).
Figure 2. Schematic representation of AHP for evaluating cloud technical fitment
Criteria pertaining to different dimensions are structured in hierarchy of levels in accordance with the AHP framework. Figure 2 shows the hierarchy structure for a technical fitment evaluation.
Remember, criteria and sub-criteria can be either quantitative or qualitative. For example "No of External System" is a quantitative value while "Well Defined Integration Point" is a qualitative one.
A cluster of criteria and its sub-criteria is called a criteria group. For example, in Figure 2, criteria "Application Design" and its two sub-criteria, "Loose Coupling" and "Virtualization," belong to same group making it a criteria group of three group members.
Figure 3 provides an illustrative list of evaluation criteria hierarchy for all three dimensions, sort of a criteria tree. While broad criteria and sub-criteria can be reused, some of the criteria would need to be tailored based on the context of an enterprise.
Figure 3. Illustrative criteria hierarchy for all three dimensions
I will show you how to use technical criteria and sub-criteria to illustrate the steps used to evaluate three sample applications for technical fitment.
Determine criteria priority
Relative priorities are assigned for different criteria using the 1-9 scale of AHP (Table 1).
Table 1. AHP's 1-9 scale of criteria priority; scale for pairwise comparison
|1||Equal importance||Two elements contribute equally to objective|
|3||Moderate importance||Slightly favor one element over another|
|5||Strong importance||Strongly favor one element over another|
|7||Very important||Very strongly favor one element over another|
|9||Extreme importance||Extremely favor one element over another|
|2, 4, 6, 8||Intermediate values|
Priorities are first determined for criteria and then for individual sub-criteria under each criteria. The sum of priorities of individual criteria in a particular level is normalized to one.
Sub-criteria have both local and global priorities. Global priority is the product of its own priority (local priority) and the priority of parent criteria. Thus global priority of "No of External System" is product of its local priority and priority of "Integration Ease."
Table 2 show an estimation of relative priority for sample level 1 technical criteria.
Table 2. An estimation of relative priority; priority calculation for criteria
|Integration Ease (IE)||1||1||0.5||0.2||0.1075|
|Application Design (AD)||5||5||3||1||0.5633|
All the diagonal elements of the matrix are 1 (the elements are compared to themselves). Comparisons in only the upper triangular matrix are done; values in the lower triangle matrix are the reciprocal of upper triangular matrix.
For example, the importance of the Technical Stack (TS) is two times that of Integration Ease (IE). The list of relative Priority and Consistency Ratio is calculated as per AHP methodology. The Consistency Ratio helps judge the consistency in pair-wise comparison.
Similarly, relative Priority is calculated for all criteria and sub-criteria. As shown in Table 3, global priority of sub-criteria is product of its local priority and the parent's priority. Thus for No. of External Systems (ES), global priority is product of its local priority (0.109586) and priority of Integration Ease (0.1075).
Table 3. Priority calculation for sub-criteria, both local and global
|Integration Ease||ES||IP||HD||Local Priority||Global Priority|
|No. of External Systems (ES)||1||0.333||0.2||0.10959||0.0117790|
|Well-defined Integration Point (IP)||3||1||0.5||0.30915||0.0332293|
|No. of HW Devices for Integration (HD)||5||2||1||0.58126||0.0624777|
Compare application against criteria
In this step, you'll see how to compare your enterprise application against both quantitative and qualitative criteria
Comparison against quantitative criteria
To evaluate the application via quantitative criteria, applications are compared against each other by taking the quantitative value for the criteria:
- For criteria that have positive impact on the objective, application scores for a particular criterion are calculated by normalizing the values to 1. For a set of numbers ri, i=1 ... n, normalized value rin is ri divided by the sum of the following of all the numbers in the set.
- For a criterion that has negative impact, relative score of applications is calculated by first taking the reciprocal of the values and then normalizing them. Reciprocal value is the multiplicative inverse of a number; the reciprocal value of x is 1/x.
Table 4 demonstrates what happens when No. of External Systems has negative impact; with the increase in number of external systems, the quantitative "score" of Integration Ease decreases. So if the three applications have to integrate with 5, 3, and 2 numbers of external systems respectively, you can see their relative scores.
Table 4. Score for quantitative criteria with negative impact
|Application Evaluation||Number of Systems||Reciprocal Value (Neg. Impact)||Score|
Comparison against qualitative criteria
For qualitative criteria, relative application scores are calculated by using pair-wise comparison using the 1-9 scale of AHP. The process is same as determining the priority for criteria.
Calculate overall AHP score
The overall AHP score of an application for a dimension is derived by the sum of the product of its relative priority in each criteria and the relative priority of respective criteria. Figure 4 shows the formula.
Figure 4. Formula to calculate overall AHP score
In this formula:
- Sx is the AHP score for the xth application.
- M is the number of criteria group.
- Ni is the number of the members in the ith criteria group.
- Pi is the priority value of the ith criteria group.
- pij is the priority value of the jth criteria belonging to the ith criteria group.
- sijx is the score of the xth application comparison against the jth criteria in the ith criteria group.
A top-level checklist for AHP
Before I wrap up this article, I'd like to provide a top-level checklist for the steps involved in using AHP to evaluate your enterprise application portfolio for its suitability in a cloud environment.
- Define criteria hierarchy
- Define criteria hierarchy for each dimension
- Tailor the hierarchy based on enterprise context
- Determine criteria priority
- Using pair-wise comparison, determine relative importance of one criteria over another
- Determine local priority for all criteria
- Determine global priority for all sub-criteria
- Determine application score for a criteria
- Using pair-wise comparison determine relative suitability of candidate applications against each criteria
- Determine relative score of candidate applications against each criteria
- For criteria having negative impact, use reciprocal value to determine score
- Determine AHP score
- Determine overall AHP score for candidate applications using formula in Figure 4
I'd like to close by first summarizing the assessment result. Once the AHP evaluation is done for all three dimensions, application scores can be collated to arrive at a decision matrix, a sample of which is shown in Table 5. The group at the top is best suited for cloud deployment; each successive group is less suited for cloud distribution.
The matrix will provide a holistic view of the impact of cloud enablement of different applications in an enterprise against different dimension and will aid in making an informed decision.
Table 5. Sample suitability decision matrix
|Application Score : Business Value||Application Score : Technical Fitment||Application Score : Risk Exposure||Suitability|
|High||High||Low||Favorable on all dimensions. Applications in this group are most suitable for cloud enablement; their score is favorable on all dimensions.|
|High||Low||Low||Favorable in two dimensions. Applications in this group are also suitable for cloud enablement; they score favorably in at least two dimensions.|
|Low||High||Low||Favorable in two dimensions.|
|High||High||Low||Favorable in two dimensions.|
|Low||Low||Low||Favorable in one dimension. Applications in this group are not ideally suitable; they score favorably in only one dimension.|
|High||Low||High||Favorable in one dimension.|
|Low||High||High||Favorable in one dimension.|
|Low||Low||High||Favorable in no dimensions. Applications in this group are best left "as-is"; their score is not favorable on any dimensions.|
Given the concerns and risk involved in cloud computing initiatives, each enterprise has to assess its application portfolio based on its business imperatives, technology strategy, and risk appetite before embarking on a flight into the clouds. With this assessment that involves multiple competing criteria of varied nature, impact, and priority, I've demonstrated how a multi-dimensional statistical approach using the Analytic Hierarchy Process (AHP) can be used to help decide which, if any, of your enterprise applications belong in the cloud.
- Wikipedia offers a quick definition of the Analytic Hierarchy Process and multi-criteria decision analysis (MCDA).
- This tutorial on "Multi Criteria Decision Making" shows you how to get deeper into using AHP, as well as some other methods of decision-making.
- We don't want you think that AHP is only good for deciding whether or not to deploy your enterprise applications to cloud: It's a really good tool for making any complex decision (ask Google).
- Check out IBM Business Analytics software.
- In the developerWorks Cloud zone, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.