Chapter 7

Architecting SaaS Solutions for Cloud Using Semi-Cloud Compatible SBBs

7.1  Introduction

This chapter gives a method of architecting cloud Software as a Service (SaaS) solutions using semi-cloud compatible products.

Hence, this chapter also tries to integrate all the knowledge a reader would have gained thus far from previous chapters.

Chapter 2 describes a couple of architecture development methods; one of the methods is for developing cloud SaaS solution for a special case of group enterprises namely for small- and medium-sized enterprises (SMEs).

The case study presented here is for developing cloud SaaS solution for SMEs, and hence the method discussed in Chapter 2 is applicable here.

Chapter 3 is a pre-requisite to grasp how Infrastructure as a Service (IaaS) works, what is auto-scaling, etc., for architecting any cloud SaaS solution, and hence the case study presented here also.

Chapter 4’s knowledge of how to architect a solution for cloud IaaS is assumed here for this case study, and it is very much applicable to all cloud SaaS solutions.

Chapter 5’s knowledge of being familiar with all the characteristics of cloud SaaS solution is a pre-requisite for architecting a solution of this nature described in this chapter.

Chapter 6’s knowledge of how to measure cloud compatibility of a given software product is essential for the solution discussed here for choosing from a bunch of possible solution building blocks (SBBs), suitable ones for the solution.

This chapter provides additional details on the following:

1. How to use cloud compatibility measures to arrive at a final choice of software products for the solution as SBBs.
2. How to come out with auto-scaling algorithm for a cloud SaaS solution based on the individual component software products (SBBs).

Software products used (SBBs), in the case study discussed in this chapter, are semi-cloud compatible; hence, they provide required but limited multi-tenancy. Since they are software products (from various vendors), solution architects have no control over their cloud compatibility nature including how many concurrent users each product in the solution can handle (for a given minimum hardware recommended configuration by product vendors).

Reference [19] contains many information discussed here.

7.2  Case Study

7.2.1  Introduction to Case Study

This case study is about architecting a SaaS solution for a group of small- or medium-segment manufacturing industry; we can refer them as a community or a consortium of enterprises. The characteristics of SMEs are a lot different, and these are discussed in Chapter 2.

7.2.2  Description of Customer

1. Customer is a consortium (community) of SMEs.
2. There may be totally about 8,000 users from about 600 enterprises.
3. It is not guaranteed that all the 8,000 users may opt to use the solution; but this number gives an idea of the maximum size of the ‘market’ for which this solution is aimed at. This number will give some business economics too.
4. If the number of users for the solution exceeds 3,000, then the consortium will take over the solution and run its operations. (This will limit the operating profit of the solution.)
5. Usage volume is not committed by the consortium at any point of time in the life cycle of the solution.
6. Some enterprises will subscribe for a large number of users, and some enterprises may subscribe only for one or two users for the solution.
7. The consortium will not invest any money.
8. Maintaining the system is the service provider’s responsibility.
9. Average literacy level of prospective users is low.
10. Solution provider can charge strictly on pay-per-use per functionality or the services consumed:
    1. Should not charge for any fees for the entire month based on logged-in users.
    2. But charging should be strictly on the basis of duration of usage of any (opted) functionality.
    3. Consequently, there cannot be any charge for enrolling in any new user such as one-time registration fees.
    4. Also, there cannot be any penalty for withdrawing or dropping any particular user.
    5. (These sub-clauses along with others imply that it is the service provider’s responsibility to maintain the users).
11. Consortium expects a proven solution and not custom developed. (This implies that solution should be an integration of proven software products rather than developed from scratch as custom modules of software).
12. Industries in the consortium are involved in textile manufacturing.
13. Each enterprise may produce one or more product or service for textile manufacturing.
14. They also compete with each other very fiercely in the same market place for their share of business.
15. Since their customers are international, each enterprise need to provide a world-class service, and some of them need to show transparency of production progress by integrating their enterprise resource planning (ERP) systems (which is nothing but the intended cloud SaaS solution) to their customer systems. (Implying each enterprise in the consortium may have their own customers and each enterprise’s data are confidential, and hence the connection to customers system also should be highly secured.)
16. Each member need to interface their systems with customers’ system for exchanging information that are relevant to customers.

7.2.3  Customers’ Requirements

1. Customer is looking for an ERP solution for textile industry.
2. Human resources management and accounting modules are also need to be included.
3. Sales, inventory and stores management features are a must.
4. Some of the enterprises or companies in the consortium may use end-to-end ERP functionalities; most of them may not use end-to-end but a few sub-modules or functions.
5. Hence, enterprises are looking for fine granular functionalities of the solution be made available as service from the intended cloud SaaS solution. That will help each enterprise can pick and choose only those functionalities what they require and pay only for them.
6. Many of the enterprises provide a specific product or service within textile industry.
7. Customers look for heavy customization of user interface, databases (DBs), mainly reports and also workflows.
8. Most member enterprises will also interface their own in-house other (information technology) systems with the cloud SaaS solution that the vendor will provide.

7.2.4  Solutions Implications and Constraints

1. The customer is not willing to invest either in hardware or software; that means the solution provider needs to invest in these and offer as a service. It is natural for SMEs to defer or avoid upfront investments.
2. There is no minimum usage guarantee or stickiness to consume the solution. This meant that neither market size was predictable nor success of solution being consumed is guaranteed. The ROI of this service eludes calculation. Therefore, even a solution provider had to be conservative in investments to provide the solution; hence, deploy the cloud SaaS solution for minimum users, but the solution should scale on demand.
3. There is a need for appropriateness (as finer as possible) in granularity of functions in the solution. That would allow member enterprises to pick and use only functionalities what each one of them requires to conserve cost.
4. It is essential to allow subscribers to perceive that the cost is in proportion to usage of functionalities.

   Customer is highly sensitive to cost of using solution: Both in pay-per-use cost per unit time as well as total duration of use.

   Each enterprise would like to customize their reports, processes or screens to meet their specific requirements. Hence, multi-tenants co-existing in the same solution instance is inevitable, which is nothing but a typical cloud SaaS solution.

5. The solution is for a group of enterprises rather than for a single enterprise (please recollect similar discussions in Chapter 2); even among those enterprises in the community providing same products or services, they differ vastly in business processes or rules. The enterprise model would not be homogeneous even to model them. In addition, many will not have any documented enterprise architecture to attempt any study and then derive some commonality among them in the enterprise models.

   Solution needs to address the following usage pattern as it is evident from the requirements:

   – Each company will use some or a few functionalities of the solutions implying fine granularity in offering solutions functionalities.

   – Need for integrating cloud SaaS solution both with each subscribing enterprise systems.

   – There could be a possibility of interfacing this cloud SaaS solution to a large number disparate systems of customer-to-customer systems.

   – The peak demand or load on any of the modules will be highly fluctuating between high and low of estimated demand.

7.2.5  Case Model

Table 7.1 summarizes unique problem this case faces^[19]:

Table 7.1  Summary of the problem in this case

7.2.5.1  Explanation for the Table

Table 7.1 summarizes the characteristics of problem and possible solutions’ space. The cross junction of these two ‘spaces’ – problem and solution – is where the solution lies.

Both problem and solution space has three major ‘dimensions’:

First in problem space:

1. The solution is for a group of enterprises and not for a single company.
2. Within that, it is for SMEs where cost is a constraint, and not for very large enterprise.
3. Usage of the solution is not predictable; hence, the cost cannot be determined in easy steps. Profitability eludes, since the consortium may take over and run the services when the number of paid users exceeds 3000.

Note: Chapter 2 completely discusses the above situation and provides how a methodology can be evolved around the central architectural development method (ADM) of the open group architecture framework (TOGAF) for these kinds of project situations.

It also has three significant dimensions in solution space:

Row 1: Using TOGAF’s ADM

1. TOGAF’s ADM for solution architecting need to be used for a group of enterprises, which is not obvious.
2. Within that ‘group of enterprises’, another special case comes in – ‘SMEs’.
3. The methodology should be taking into account the uncertainty in the usage model and hence pricing model.

(A solution for this – a methodology for architecting cloud SaaS solutions for SMEs – is completely discussed in Chapter 2).

Row 2: Using semi-cloud compatible products to provide cloud SaaS solution

1. Using semi-cloud ready commercial off-the-shelf (COTS) as SBBs for the solution for group of enterprises.
2. Cost will dictate selection and optimal use of COTS products for the solution; hence, less cloud compatible products may be forced into the solution.
3. But the final solution should behave as if it has absolute cloud compatibility.

Row 3: Architecting a cloud-based SaaS solution (rather than conventional hosted model).

7.3  Architecting Solution

7.3.1  Building Business Capabilities for a Group of Enterprises

Identifying architectural building blocks (ABBs) by appropriately grouping the requirements is one of the first significant first steps in architecting solution. Chapter 2 has discussed this step in detail. Chapter 4 has illustrated this step though a solution that is non-cloud SaaS solution, the illustration is useful for novice professionals.

(Next major step is to locate suitable SBBs to meet the ABBs. But before that step)

From the functional requirements and the ABBs determined, architects can come up with a preliminary functional architecture. Key modules required for this solution is ERP module. One can further detail various sub-modules that are required for the solution. HR module is also required but assumed to be part of the ERP module for referring here.

An RDBMS package is essential but that cannot be counted as functional module.

Other software required (including infrastructure software such as operating system, app servers, Web servers, anti-virus software, etc.) are based on technological requirements. These are also not functional modules.

There may be more than one possible SBB option that could have been identified matching each ABB. Then, each SBB need to be further analysed for cost effectiveness by analysing their license fee, implementation and maintenance cost.

That will give a set of short-listed options of SBBs against each ABB. In this set, we need to run the cloud compatibility measure on each of the SBBs, as discussed in Chapter 6. Subsequently, one that scores more cloud compatible can be finalized.

Sub-section 7.3.2 gives an overview of cloud compatibility discussions done for this ERP module.

7.3.2  Calibrating COTS against Cloud Compatibility Criteria

Within the cloud compatibility criteria discussed in Chapter 6 and in Table 7.2, the discussions narrow the characteristics expected out of SBBs. Therefore, evaluation of each software product, that got qualified as SBB, need to be carried out keeping these additional narrowing down criteria. The final selection depends on the closeness of expectations mentioned in Column 3.

Table 7.2  Calibrating COTS against cloud compatibility criteria[19]

7.3.3  Key Challenges and Solutions in Finalizing SBBs

Table 7.3 below indicates how the solutions have been finalized against odd or challenging reality. The column to the right indicates the final decision taken in this solution against those cloud compatibility criteria.

Table 7.3  Key challenges and solutions in finalizing SBBs^[19]

7.3.4  Security Requirements and Solutions to the Final Solution

Customer’s security requirements were very simple. Enterprises expected a basic data protection for privacy and the entire cloud is private and visible only to subscribers. (This is typically a community cloud meant only for a set of known possible customer enterprises.)

7.4  Summary of Cloud-Based SaaS Solution

Having selected and finalized the required SBBs, the solution architecture can be drafted. In this case, it will be as follows:

7.4.1  Deployment Architecture for Minimum Usage

1. Terminal server (software from Microsoft^TM) (Figure 7.1) will act like Web tier software to handle all incoming HTTP requests or page requests; each instance of the terminal software can entertain comfortably 50* simultaneous users.
2. MS Navision^TM can be assumed to be the ERP software; this is multi-tenanted, but each software instance cannot handle more than 200* simultaneous logged-in users.
   

   Figure 7.1   Terminal server, auto scale to accommodate 200 users

3. MS SQL server is the chosen DB.
4. Other supporting software are Active Directory^TM/Lightweight Directory Access Protocol^TM(LDAP).
   1. One instance is enough for all 8,000 users or even more.
   2. Of course antivirus software.
5. Users will be validated and authenticated through Active Directory^TM/LDAP^TM.
6. Authorized users will be allowed to use the signed up (or permitted) features in ERP software.
7. ERP software will use the RDBMS.
8. For each customer, same RDBMS is used but different schemas. This also will help them have their custom reports and information collection for the same purpose.
9. A SAN is used for data storage.
10. All the hardware are under a hypervisor and h/w infrastructure is virtualized using techniques similar to the one described in Chapter 4. Additional instances of the hardware can be requested on-demand, thanks to the hypervisor’s ability.

7.4.2   Evolving Deployment Architecture

The steps mentioned here are very similar to the ones mentioned in Chapter 4.

The first step is to arrive at deployment architecture of minimum configuration for minimum usage (see Figure 7.2). In our case, it is for about 50 users.

Figure 7.2   Deployment architecture for minimum usage – 50 logged in users

7.4.3   Size Software for Scalability

The second step is to identify the scalability factors for each of the software.

For terminal server, the maximum number of users per box* can be only 50. Therefore, for every additional login user beyond 50 users, we need one more set of hardware box* and an instance of the software to entertain additional incoming users to maintain the same response time.

For the ERP software, one instance can handle up to 200 users. For every user beyond 200 till the next limit of (additional 200) 400, we need one more set of hardware box* and corresponding software instance. This includes the operating system and the associated micro-ERP software.

To coordinate these two ERP servers, a load balancer is essential; this can be even software as in this case.

However, RDBMS software normally does not scale based on the number of users. The ideal parameter is the central processing unit (CPU) utilization and memory utilization. If CPU utilization crosses 40 per cent or maximum of 60 per cent and memory utilization crosses 60 per cent, it is better to kick off its next instance. There are many ways of calculating the scaling trigger point for RDBMS package. The above is not true always, but useful common way.

7.4.4   Determining Scaling Algorithms

The auto-scaling algorithm will be more like the one listed below:

1. For the first 50 users, the minimum hardware/deployment configuration will work.
2. The moment 51st user logs in till 100th user, the next instance** of terminal server will start, and this process repeats for every additional 50 users.
3. When the total number of users crosses the first 200, the next instance** of ERP server will also start; this will repeat for every 200 users. Bring a load balancer to coordinate these two servers.
4. RDBMS software will start next instance** based on the composite parameter of CPU utilization and memory utilization.

7.4.4.1   Scalability and Performance Illustration

1. Figure 7.3 explains how the scaling will occur as and when new users log in. This is in tune with the scaling algorithm explained in Section 7.4.4.
2. For first 50 login users there will be only one terminal server and one ERP server will be deployed.
3. On 51st new login user, the second terminal server will be kicked-in to work, that the first scaling occurs.
4. On 101^st and 151^st, new simultaneous users, third- and fourth-terminal servers will be brought to live.
   

   Figure 7.3   A snap shot of actual auto scaled-up architecture that is serving when the users are above 600

5. On 201th new login user, second cluster will start with one terminal server and one ERP server. This second cluster will keep scaling by adding additional terminal server until its 200th but over all 400 users log in… and so on.
6. In all the above situations, the hardware housing RDBMS, anti-virus, active directory server will be only one. (RDBMS server scaling is not dependent on number of login users; it depends on how intensive the computational work is invoked by users; even if less than 50 users invoke a large CPU time or memory intensive work at data tier (assuming RDBMS will be directly taxed), it will begin to scale as per its scaling algorithm mentioned in Sections 7.4.3 and 7.4.4).

7.5   Other Routine Steps for Implementing the Solution

1. The steps mentioned in Chapter 4 for choosing IaaS is applicable here.
2. Choose the appropriate hardware instances in the targeted virtualized IaaS environment.
3. And install each of the SBBs/products in the appropriate instances.
4. Install also the scaling algorithms using the provisions in the virtualized environment – this will be mostly using a cloud watch patterns.

7.6   Less Cloud-Ready Software Costs More for Per-User/Time

The cost to end-user is directly dictated by the maximum number of users that can be accommodated in one unit of deployment hardware configuration. Here for 200 users, the solution needs four terminal servers and one ERP server. Therefore, the cost of these 4+1 servers is divided by 200 users. If, say, 30 more users logs in, then they cannot be accommodated in the running 4+1 servers. Additional one each of terminal and ERP servers are required as explained in the scaling algorithm. Therefore, the cost does not always go down with increased users. Further, the cost of the solution is dictated by maximum number of users that can be accommodated in single instance of software.

If the software is highly scalable, it can accommodate more users per instance, and hence cost of hardware required per user will be less.

Therefore, configuring minimum deployment architecture, and providing scaling algorithm almost brings the solution architecture phase to conclusion.

7.7   Summary

The key takeaway from this case study are as follows:

This use case:

• Summarizes experiences in architecting a solution as follows:

  – For a group of enterprises rather than for a single entity.

  – For using semi-cloud-ready software to provide cloud-based SaaS solution.

• Summarizes key challenges and solutions.
• Contributes the following to architect cloud-based SaaS solution for a group of companies.
• Uses the measure for cloud-readiness to select the needed SBB for building cloud based SaaS solution.
• Provides detailed steps to build a cloud solution.

Recommendation for further work

1. Although ADM’s steps are technology independent, the open group can give some guidelines on optimal set of steps for architecting cloud-based solution.
2. We need to examine our reference models and enterprise continuum to include cloud extension of corporate assets to represent in EA repository.
3. Architecture forum such as TOGAF can examine more formally the use of ADM for applying or using the same in situations such as providing solutions to group of enterprises as the need for the same is going to increase.
4. Coming up with a systematic set of criteria to calibrate any given software for ‘cloud-readiness’ seems to be a must. I tend to recommend a software product – neutral body can bring a regulation even to stamp them for its cloud readiness using the commonly agreed criteria.
5. Also, the software products can contain scaling guidelines rather than relying on experience from other projects. Right now, mostly we find a suitable hardware configuration for deploying them.