Chapter 6

Cloud Compatibility Measure

6.1  Introduction

For architecting a software solution, we need a lot of solution building blocks (SBBs) that make up the solution. Each of the SBBs may be mapped onto one or many software products. Chapter 18 in Ref. [21] indicates how to architect solutions using off-the-shelf components or software products. For cloud Software as a Service (SaaS) solutions, it is preferred that each of this software products also be a cloud compatible SaaS product. (This chapter gives the answer to the question ‘Why is it preferred?’.)

Expected ideal characteristics of a SaaS software – be it a product or solution – is discussed in detail in Chapter 5. In reality, many of the software products do not meet this long list of ideally expected characteristics of SaaS.

This chapter proposes and discusses an empirical method to measure how much of these characteristics are met by any given product. Such a measure is here referred to as cloud compatibility measure.

6.2  Motivation to Come Up with Cloud Compatibility Measure

This measure is a kind of yardstick that is used to measure against and compare products to know how much they are cloud compatible.

Such a comparison will help in selecting better suitable products to meet SBBs for building cloud SaaS software solution. While other factors such as functionalities or performance, etc., being equal in meeting the requirements, the one having better cloud compatible index will be selected.

In addition, this book discusses that SaaS solutions are possible with three kinds of cloud compatible indexed products: (qualitatively speaking) (1) fully cloud compatible (100%) products, (2) fully non-compatible (0%) products and (3) semi-cloud compatible (anywhere in between 0 and 100%) products.

Making a software product fully cloud compatible requires re-architecting and building it ground up^[23] as discussed in Chapter 9. Such an effort is huge and justifying with a business case or providing a convincing ROI may even elude. Therefore, the market will continue to have semi- or non-cloud compatible products that architects have; no other choice but, to use them to build cloud SaaS solutions.

Also business requirements or business models may dictate whether it is essential to go for absolutely cloud compatible SBBs to build cloud SaaS solution. The use case given in Chapter 7 demands low-cost solution (security is not a major issue), and hence there is no need to use (may be costly) SBBs that are perfectly cloud compatible to build a cloud SaaS solution.

Hence, architects may have to use less (or non-) cloud compatible SaaS products as SBBs to build cloud SaaS solutions.

Thus, there exists a necessity to have techniques to architect solutions with products having any degree of cloud compatibility; that has resulted in such techniques described in this book – Chapters 7 and 8. This chapter provides a preliminary step for those techniques: measuring ‘cloud compatibility’.

By following techniques described in this chapter, if product vendors also mark on their product brochure as to what extent their products are cloud compatible, that information will reduce a lot of effort for solution architects.

Just like specifying ‘minimum hardware required’ or suitable ‘operating system’ on the pack of software products, vendors can specify ‘cloud compatibility index’ also.

Cloud compatibility measure as applied to any existing products has other uses such as to improve them to make them absolutely cloud compatible, if that is an objective.

While that gives enough motivation to come up with a common yardstick for cloud compatibility measure, let us see how a scale can be set up as well as how the scale can be used.

6.3  Definition of ‘Cloud Compatibility’

How to define ‘cloud compatibility’? A software is said to have complete cloud compatibility if it has all the necessary characteristics (mentioned in Chapter 5) to the desired level. If it does not have even a single characteristic, then it is said to have absolutely no cloud compatibility. This is more of operational explanation rather than a theoretical definition.

Cloud compatibility is referred with respect to its ability to satisfy all characteristics necessary to become very efficient cloud SaaS software.

Literature Refs. [5, 24, 37] cloud compatibility in various different ways – one of them^[24] is whether a cloud SaaS software service is compatible to in-house software. We do not enter into any such meanings.

There were similar thinking to measure cloud compatibility, and a need was felt by many in the past; here, we will review one prominent and the most comprehensively discussed in literature^[5] before embarking into the main idea of cloud compatibility that this book prefers to explain and use in the remaining chapters.

6.4  SaaS (Solutions) Maturity Model

Reference [5] uses a terminology ‘SaaS maturity model’ as a way of measuring cloud compatibility. A fully matured SaaS product is the ultimate cloud compatible product. Thus cloud compatibility measure is also a way to measure SaaS maturity of the software.

The term ‘maturity’ also indicates that softwares need to progress (mature) in this direction of having absolute cloud compatibility.

Although Ref. [5] identifies four levels of maturity, it has acknowledged that SaaS maturity is on a continuous scale. That means cloud SaaS maturity is in a continuous scale of 0 per cent through 100 per cent as this book points out the cloud compatibility measure.

As per Ref. [5], the basis for SaaS maturity is based on three characteristics of a SaaS software: scalability, multi-tenant efficiency and configurability.

Based on the three characteristics, the Ref. [5] defines four distinct levels of maturity:

1. At zeroth (or technically the first level) level, all the three characteristics are absent.
2. At the fourth level, all the three characteristics are fully present to desired degree.
3. Each level is distinguished from the previous or other levels by addition or absence of one of the three attributes.

Refer to Figure 6.1 below^[5]:

Level 1: Ad hoc/custom

1. Each customer has its own customized instance.
2. Has customer-specific hardware for each instances.
3. This was popular in 1990’s and referred to as ‘hosted model’ (see Chapter 1).

Figure 6.1  Four levels of cloud SaaS maturity model^[5]

Level 2: Configurable

1. Same as Level 1 but with one difference that the software is configurable. Hence, each customer will have their own same code base since their configuration customization would have changed the initial common code base.
2. Upgradation of software is possible across customers.

Level 3: Configurable, multi-tenant efficient

1. Single instance serves many customers.
2. Use of metadata for keeping the configuration parameters set to each customer.
3. From end-users’ perspective, they are unaware of the existence of other customers using the same instance.

Advantages:

1. Same hardware is efficiently shared across customers and cost saved.

Disadvantages:

1. It cannot scale efficiently; scaling (scaling up) by moving to more powerful hardware is the only possible solution.

Level 4: Scalable, configurable, multi-tenant efficient

1. SaaS providers can host multiple customers.
2. A load balanced form of identical hardware instances help scaling up or down ondemand.
3. Rolling out updates to the software is easy, since it is single instance at single point.
4. Customer data can be kept separately.
5. Configurable metadata provides a mechanism for both recording preferred user experience and as well as highly flexible and rich user experience provisions^[5].

Thus level 4 provides all the advantages.

1. The above model is good to understand the subject ‘cloud compatibility measure’.
2. This model is proposed from the perspective of revamping (re-architecting or redeveloping) or maturing any existing software product to make it a cloud compatible SaaS software. Therefore, how to make a product more ‘mature’ as a cloud SaaS software is the key perspective here.
3. Such a measure sets a goal or target state to be aimed at; as well as it defines a path to travel to reach the target state. The ‘goal’ or ‘target state’ is reaching level 4. ‘The path’ to travel is improving from level 1 through level 4.
4. But from the perspective of architecting a SaaS solution for cloud, this measure is not adequate.
   1. Solutions architects face, most of the time, a situation to select a product from a set of available ones in the market. Among the choices of products available, solution architects need a measure to compare otherwise equal products to choose a much more matured SaaS software. From that perspective, defining a measure is attempted in this chapter.
5. SaaS maturity model discussed so far, makes use of only three characteristics of software for measuring SaaS maturity; the one discussed in this chapter takes into account all the characteristics of cloud SaaS software as solution architects need many intermediary levels between the first and fourth.

6.5  SaaS Maturity Continuum Scale

The same Ref. [5] also brings in an interesting observation that SaaS maturity (Figure 6.2) is not ‘all or nothing’ proposition.

It is better to visualize SaaS maturity as a continuum between isolated data and code on the one end and shared data and code on the other end^[5].

Per-tenant SLA, code and data isolation are at the one end, and economy of scale and simpler management are at the other ‘sharing’ end.

On declaring a software – be it product or solution – being fully matured (as SaaS for cloud), the code of the software’s single instance is sharable across multiple companies for simultaneous use, whereas the data are preferably isolated from one enterprise to another. That is at the highest end of fully matured desirable SaaS solutions or products.

Contrast this to lowest level where the data and code are isolated from other enterprises.

The continuum only supports a reality between these two extreme ends where there are numerous possibilities.

The numerous possibilities are due to variation in the levels of each of the characteristics of SaaS software.

This principle of ‘maturity continuum’ is applicable to cloud compatibility also. ‘Cloud compatibility’ is also not ‘all-or-nothing’. Its value ranges from 0 to 100 per cent, and there can be many intermediate values. (Even at 0% still one can possibly build a cloud SaaS solution using the same, but the cost of it may be higher.)

Figure 6.2  SaaS maturity as a continuum scale^[5]

6.6  Cloud Compatibility Measure

This section describes how to measure cloud compatibility of a product. This is an empirical method. This section also shows an example of how to put in use to select products that are more cloud compatible while architecting cloud SaaS solutions.

There are three sub-sections within this section:

1. Section 6.1 discusses a method to set up cloud compatibility measure (for the purpose of solutions architecting or evaluating a product).
2. Section 6.2 indicates ideal values for each of the characteristics of the ultimately cloud compatible SaaS solutions or products. It also discusses or reveals further details of measure.
3. Section 6.3 discusses on applying this measure to products through a case situation.

6.6.1  Procedure to Set Up the ‘Cloud Compatibility Measuring Scale’

This section describes a procedure to arrive at cloud compatibility measure for products in an architecting project. The procedure consists of setting up or defining a scale and then use it to measure ‘cloud compatibility’ for each components or products that need to be evaluated for providing cloud-based SaaS solution.

In this method, architects use an ideal ‘value’ for each characteristic of fully matured SaaS software – Solutions or products. Ideal values are described in Section 6.2 for most of the characteristics and are listed in Table 6.1.

For example, against a characteristic of ‘business rules’, an ideal value suggested in the table is ‘alteration of business rules can be allowed to alter workflows/business processes’. The value indicates the solution that allows customers to define or modify default business rules that come along with the software; and at the same time when such an alteration is done, the system automatically points out all the other areas that also need to be modified. For example, sometimes a change in a particular business rule, such as approval amount being increased from a default of 5000–10,000 rupees, may prompt for altering workflow, such as to get additional approval from the senior manager of the bank; otherwise, the manager him/herself can approve.

Complete absence of the ideal state, for any characteristic, is assigned a value 0. In the above example of business rules, the pre-defined business rules cannot be altered by any subscriber to cloud SaaS.

A software product or component is said to be cloud compatible fully if it meets the ideal state for all the characteristics.

Complete absence of the ideal state for all the characteristics is assigned 0 per cent compatibility.

Between these two extreme values, architects are encouraged to use or define either 5 or 10 levels. (See Table 6.2 along with the case study discussed in Section 6.3 for an illustration of this point.) Weighted average method is used for commercial off-the-shelf (COTS) product described in the case study in Section 6.3 and Table 6.2 will show the values.

Table 6.1  Cloud-compatibility calculation

Table 6.2  Cloud-compatibility measure for two products

For example, for the characteristic cloud SaaS architecture, there are about nine possible values that are indicated in Table 6.1. In addition, Table 6.1 gives a lot of possibilities for value for each characteristic (whether those characteristics do matter or not and hence what are the values that need to be chosen can be project specific).

Solution architects should have the flexibility to define each level and criteria to determine and assign a value to each level.

Criteria for determining levels may be unique for each characteristic (attribute); it can vary from solution to solution as the solution architect decides.

The variation from solution to solution may be due to project requirements or criticality of that parameter for that product. Defining intermediary values also depends on the business requirements and the criticality of the characteristics of SaaS to the project.

This will look like a laborious process for the first time, but its continuous use will accumulate the values and criteria defined for each project. The accumulation will serve as a project asset for subsequent projects too.

Constant use of this method will provide a ready reckoner for many software products being used in various project situations.

Evaluating and accumulating such values for infrastructure software products – such as operating systems, app servers, portals, e-commerce products and content management systems – will be used repeatedly for most of the subsequent projects.

This work is less for solution architects, if the product vendors provide more generic and absolute measure of cloud compatibility value for each of their product.

Also use of weightage for the characteristics is sometimes appropriate and recommended.

Such pre-determination to assign weightages clearly brings out the priority of the characteristic that the architect is looking for in that solution.

Sometimes, it is not possible to find 5 or 10 different intermediary levels for some of the characteristics. In that case, architects can settle for only three distinct intermediary levels too. Assigning lower weightages to those characteristics is normal practice.

Instead of finding 5 or 10 distinct levels, it will be advisable to use a grading system. In this case, a score between 0 and 10 is assigned, based on architects’ judgement about the characteristic for a given product, for each characteristic of the product. And collective grade is determined based on total score obtained.

If weightage is used for each characteristic, weighted average score is calculated for each competing product and the results are compared.

Alternative to find 3 or 5 or 10 different intermediary levels, a simple ‘yes’ (100% compatible) or ‘no’ (0% compatible) scheme will also suffice.

6.6.2  Ideal Values for Characteristics

Chapter 5 discusses highly desirable characteristics of SaaS solutions and products.

This section summarizes the essentials, from there, required for the purpose of cloud compatibility measure.

Refer to Table 6.1 and the explanation for the table is as follows:

1. Against each attribute, the table lists as much as possible idealistic expectation.
2. In a way, this is a different collated tabular summary of what is discussed in detail in Chapter 5. Therefore, comprehending Chapter 5 is more important.
3. Each of the values against any attribute is explained in Chapter 5; some understanding of importance of these values can also come from Chapter 9.
4. The list is not exhaustive.
5. Certain attributes such as ‘multi-tenancy’ or ‘scaling’ depend on many other (sub-) attributes; those attributes are highlighted bold and against them no values are provided.
6. It is very difficult to indicate which one should be given a higher importance weightage or priority.
   1. But the presentation is such that: for any attribute, the highest idealistic figure is given in the left-most column (column 2), and the least important values are given in the columns as far to the right as possible.
   2. For some of the attributes, all possible 10 values are given; for most of them, all the 10 values are not possible to list because it may not make sense.
   3. Depending on project requirements and situation, priority of values for any attribute need to be re-assigned; also priority among the attributes may need to be re-arranged; the list does not suggest any importance or priority among attributes; in some projects, certain attributes is not at all important.
   4. Also based on the same – project requirements and situations – may be many more ‘values’ that are not listed in the table can be considered.
7. Although listed last, examining and giving high importance to SaaS software’s architecture is most recommended.
8. Multi-tenant efficient is mostly described in the table as a comparative measure between two and more products or solutions. The data that need to be collected are indicated there in the table column; but the comparison can be done in the following way:
   1. First collect for each module or tier or component how many number of users it can accommodate for one instance on one deployment infrastructures set.
   2. The <total cost of deployment infrastructure> divided by <the maximum number of users it can accommodate> gives one measure called ‘module cost per user’. But that is not enough.
      1. Some of the ‘modules cost per user’ may be low or high; it does not indicate any.
      2. Comparison of ‘cost per user’ for the entire deployment infrastructure can be used between two different competing products or solutions.
      3. But sometimes, the above may be deceiving; all the users may not go through all the modules (or tiers); therefore, it may be appropriate to select a set of most frequently used modules and calculate their cost per user and compare them.

6.6.3  Case Study – Measures for Two Products of Similar Functionalities

6.6.3.1  Introduction to this Illustration Through a Specific Case Study

1. The actual product names are purposely avoided.
2. The application for which these products are compared is to develop a cloud-based enterprise document storage solution.
3. Enterprises (subscribing customers’) main criteria were of the following
   1. More of low-cost solution (pay-per-use)
   2. Ability to interface with many in-house systems
   3. Ability to interface with other cloud services such as Salesforce.com^TM or Google^TM maps, etc.
4. The content management system needs to work with Salesforce.comTM (another commercial cloud SaaS service) to exchange stored multi-media content.
5. The cloud enterprise content management (ECM) SaaS solution also needs to interface with other enterprise systems across enterprise boundary from its own cloud (outside enterprise boundary).
6. The objective of this exercise is to select one good cloud compatible software product so that a better cloud SaaS solution can be built to meet customers expectations.
7. Two ECM software products, which are used for required solution, are compared here: one is open source and the other is a COTS product.

6.6.3.2  Open-Source ECM Products Basic Information

1. The product basically has multi-tenant architecture.
2. JBPM^TM is used as its Business Process Management (BPM)/workflow engine; this can accommodate multiple tenants so that any subscribing customer can customize workflows within the product.
3. Has a multi-tenanted database to accommodate most of cloud ECM SaaS solution.
4. It has an open RDBMS software that is also multi-tenanted.
5. Most of its functions are exposed as service APIs; it is not clear whether its intertier communications are service oriented; but being open source, the source code is available for any modification required.
6. It is built on J2EE platform.
7. Being open source, it can be made amenable for many things:
   1. Run time hot swap of upgraded software.
   2. Security can be implemented as ‘aspect’ using spring^TM or any such platform.

6.6.3.3  COTS ECM Products Basic Information

1. This COTS is an established product in the market.
2. This is also a Java-based system.
3. The product is in existence even before cloud computing becomes popular.
4. On license basis, this software can be procured and integrated with rest of modules for any solution, or it can be in used standalone in enterprises for content management needs.
5. It is a multi-tier architected product; implying scaling can be supported through additional hardware for the required bottlenecked modules or tiers.
6. Functionalities are exposed as services for consumptions.
7. Inter-tier communication within the product is not service oriented.
8. Obviously, source code is proprietary and not available for solution architects to modify them to suit solutioning requirements.
9. The concept of multi-tenant has to be simulated outside this product for subscribing enterprises.
10. Individual subscribing enterprises content need to be stored in a labeled file folder. Customizing subscriber-specific user interface or storage is not possible.
11. Workflow or BPM is an external module whose license needs to be purchased separately. BPM module is also not architected for multi-tenants.
12. Storage use for every user needs to be calculated by an external module based on file size both during storing and deleting. This is a round-about means; laborious custom algorithm needs to be developed and implemented separately for this functionality; it will consume additional time during file creation and deletion.

6.6.3.4  Selection of Product Based on Cloud Compatibility Measure

The following discussion is based on Table 6.2 where the above discussed two products cloud.

1. Although all the attributes’ values are listed for both the products, the architecture of the products immediately reveal which one is more cloud compatible.
   1. Architecture indicates the open-source software is more cloud compatible and also being open-source amenable for implementing needed aspects.
2. (This example chosen here is two extreme end-products for comparison; and hence the difference between them or which is more cloud compatible than others is pretty clear, hence the resultant choice. But the way to go about is what is more important).
3. The open-source product (OSP) is declared by the software publisher as multi-tenanted.
4. OSP has a dedicated workflow/business process engine that is also multi-tenanted; hence, each customer can customize workflows/BPM to meet their requirements.
5. Since the solution is on content management, it is expected that each user and hence each subscribing tenant enterprise will have different storage needs. Ability to finely measure the secondary storage use and also ability to allocate additional storage space on-demand are important characteristics expected. This is directly possible with least development effort for OSP-based solution compared with the COTSbased solution.
6. The COTS product does not have service APIs to integrate with other cloud services or other enterprise systems, whereas as the open source had a reasonable interoperable services, it is expected to have easy connections to other cloud services such as Salesforce.com^TM or Google’s^TM cloud services (including maps).
7. For the project, comparing these characteristics adequate to select the final ECM product.

The above discussions and the comparison chart (Table 6.2) clearly indicate what can be the product of choice for the solution. Obviously, the cloud compatibility of the ‘opensource product’ is more than the COTS. Here, an absolute measure on the maturity or ideal perfect cloud compatibility measure is not attempted. Relative comparison is adequate for selecting products as SBBs suitable for cloud SaaS solutions.

6.7   Combined Discussion about All the Three ‘Cloud Compatibility Measures’

This chapter discussed the following three models of cloud compatibility measure:

1. The ‘SaaS maturity model’ referred in Ref. [5] and discussed in Section 6.4.
2. The cloud compatibility measure that is discussed in sub-section 6.6.1.
3. A variation of ‘cloud compatibility measure’ where in to use many intermediary values between 0 and 100 per cent compatibility with weighted average among the attributes discussed in sub-section 6.6.1.

Some observations about these (cloud compatibility measuring) methods are as follows:

1. The first level or the lower extreme end of all the three methods discussed here coincides – it is not at all cloud compatible in the scale.
2. Similarly, the fourth level of matured product coincides with the absolute cloud compatibility of the scale.
3. The major differences between the two models of measure suggested in this chapter and that of the one in Ref. [5] are as follows:
   1. The fine difference between two extreme ends is essential to compare many maturing products coming up in the market. Maturity model^[5] gives only four levels, whereas ‘the cloud compatibility measure scale’ gives flexibility to set a large range value from 0 to 100.
   2. Assuming only two stages between ‘nothing and all’ as mentioned in SaaS maturity model is good if one plans a road map for a product to mature to the fullest level; even in that situation, this book suggests it is better to have many more finer milestones on the road map of maturity (to reach the target architecture) rather than confining only to two major milestones.
4. In ‘cloud compatibility measure scale’, the intermediary levels can be fixed to serve many purposes: for example, for measuring maturity with calculated ROI for every additional compatibility the product gains.
5. ‘Cloud compatibility measure’ method is more of practical use also in the solution architecting space, especially to select a product or component objectively from a qualifying list of them. There the solution architects have least influence on the product architecture or its current status. This is a little pragmatic empirical way to convince the stakeholders for the choice made. In addition, it has a good engineering analysis basis.

In conclusion, the ‘cloud compatibility measure’ introduced in this chapter can be used both for selecting most suitable product as SBBs while architecting solutions and for re-architecting a given product and draw a road map for making it completely cloud compatible.

6.8  Summary

• This chapter discusses motivation for devising a cloud compatibility measure.
• It describes an empirical method that is handy to use both for:
  1. Selecting most suitable one from competing products while architecting a cloud SaaS solution.
  2. Finely defining a road map to make any given product to be absolutely cloud compatible.
• The cloud compatibility measure is compared and discussed with a SaaS maturity model of Ref. [5].
• It showed a few variation of using the cloud compatibility measure scale and that will be handy to tweak it depending on the practicality of any project situation.
• It also illustrated the scale’s use through a case study.