Applying AHP

To apply the process of decision aiding with AHP the Web application developed and described in Chapter 6 was used. Some of the steps of the process will now be described.

7.1.2.1 Filling-in the Criteria and the Scenarios

To use the information of the defined criteria with AHP it was necessary to first verify if all the criteria were independent of each other, since AHP does not support criteria dependence, and also define the hierarchic structure of the criteria, grouping the related criteria under a common criteria.

In terms of criteria dependency the criterion Redundancy and the criterion Load Balance share always the same value, no matter the scenario. Although they are different they are connected, because both are dependent of the server structure. This relation of dependence would influence the process, with alternatives getting double preference for the same characteristic of the solution, the server structure. Due to this it was decided to consider only one of these criteria in the application of AHP. It was decided to consider the criterion Load Balance. Besides this particular case all the other criteria were independent from each other.

Regarding the hierarchy among the criteria it was decided to arrange them in four groups, based on their similarity and their characteristics. These groups and the criteria that belong to them are the following:

 CMST Related: Hours of development, codebase type, Security, Built-in Applications, Ease of Use, Deployment, and Update Web Applications, Added

Value;

 Hosting Related: Portability, Scalability, Load Balance, Backup of Data and Applications, Backups Redundancy, Server Updates, and Server Maintenance;

 Cost: Launch Cost, and Cost per Project

After the hierarchy of the criteria was defined the information related with the criteria was added to the Web application, as it can be seen in Figure 14.

Figure 14 Applying AHP - Criteria List

After all criteria was added to the Web application the next step was to add the

information of the different scenarios. The result of this step can be seen in Figure 15.

Figure 15 Applying AHP - Scenarios Information

In the Application the scenarios‟ name are created squentially. So as can be seen in Figure 15 the scenarios are named differently from the names used in Chapter 5. To avoid confusion, especially when analysing the results, Table 4 Scenarios Denomination establishes the relation between the denomination used in Chapter 5 and the one present in the Web Application. In this chapter it will be used the denomination from the Web Application to facilitate the reference to the figures.

Table 4 Scenarios Denomination

Name in Chapter 5 Name in the Application Description

Scenario 1 Scenario 1 MOSS 2007 in AWS

Scenario 1.2 Scenario 2 MOSS 2007 in AWS with

bigger server structure

Scenario 2 Scenario 3 Custom CMST in

Microsoft Azure

Scenario 2.1 Scenario 4 Custom CMST in

Microsoft Azure with bigger server structure

Scenario 3 Scenario 5 Umbraco in TerreMark

Scenario 3.2 Scenario 6 Umbraco in AWS

7.1.2.2 The Pair Wise Comparisons

After adding the information of the criteria and the scenarios it was time to start the pair wise comparisons towards to prioritize the alternatives. This was the longest part of the application of the AHP. The first comparisons were of the main criteria, then for each main criteria their sub

criteria were compared to obtain their priorities, and then it was time to compare all the scenarios regarding each criterion.

These comparisons were made through direct questioning of the Decision Makers (DMs).

Together they defined their level of preference of one element over another for each pair wise comparison. This process was followed as carefully as possible to avoid inconsistencies.

Inconsistencies normally fail to reflect the real preferences of the DMs. An example of an inconsistency is: When one defines that an element A is more important than an element B, and then defines that element B is more important than an element C, and finishing the comparison by defining that element A is less important than element C. Although inconsistency is inherent to a process like this where different judgements are made it should be avoided whenever possible. Otherwise, a high level of inconsistency will bias the results, and make them of low interest.

In Figure 16 one of the comparison screens can be seen. This one is the comparison of the sub criteria that are under the “Hosting Related” criteria.

Figure 16 Applying AHP - Comparing Sub Criteria

After the necessary comparisons were made the application calculated and presented the results of this process.

7.1.2.3 AHP Results

With the information provided the Web Application calculated the priority of each scenario. In the results page it is presented a ranking of the criteria, which can be seen in Figure 17. This ranking is based on the priorities calculate through the pair wise comparisons.

Figure 17 Applying AHP - Criteria Ranking

In this ranking the criterion “Backup of Data and Applications” shows up as the one with highest priority, or preference. It is then followed by the “Launch Cost” criterion, and the

“Codebase type” criterion. The ranking goes on listing all the criterion. In the last position is the criterion “Update Web Applications”.

Besides the global priorities of the criteria the Web application also calculates and displays the priorities of the scenarios. These priorities as well as the detailed priority of each scenario in relation to the different criteria, are shown in Figure 18, Figure 19, and Figure 20.

Figure 18 Applying AHP - Results 1

Figure 19 Applying AHP - Results 2

Figure 20 Applying AHP - Results 3

In each column the highest value is represented in bold. These results point the scenario number 3, which is composed by a Custom CMST hosted in Azure Services Platform, as the one with higher priority.

Although this page is named the results page the AHP decision aiding process did not end here. The next step of the process was to analyse the results obtained.