Chapter 8

Architecting Cloud SaaS Solutions with Cloud Non-Compatible Products

8.1  Introduction

Chapter 7 describes how to architect cloud Software as a Serive (SaaS) solutions using semi-cloud compatible software products. Chapter 9 provides a complete discussion on how to architect cloud SaaS products that are aimed to be absolutely cloud compatible. The information found in these two chapters will definitely also be useful to architect solutions using non-cloud compatible software products. As discussed in Chapters 1, 5 and 6, very often solution architects are forced to provide a good cloud compatible SaaS solutions using cloud non-compatible (cnc) software products.

To recap quickly, the main reasons are the following:

1. Many of existing software products are not cloud compatible.
2. It may take long time (and cost) for software product vendors to re-architect their software products.

Therefore, architects have to live with the reality of providing cloud SaaS software solutions using utterly non-compatible cloud software products. This chapter shares experience of such situations. Solution architects can benefit of the discussions in this chapter. The technical architecting method shown and adapted in this chapter cannot be generalized and applied to all solutions that use absolutely non-cloud compatible software products.

8.2  Classification of Solutions Using Not-at-All Cloud Compatible Products

A typical industry grade software solution may typically require more than 5–20 different software products: big or small. A few of them may provide main functionality for the solution. If some of the remaining software products are not main and happen to be non-cloud compatible, then architecting a solution is relatively easier and not discussed in this book.

If the main software products required for a solution are not fully cloud compatible, some of the techniques discussed in this chapter can be used.

Figure 8.1 summarizes the possibilities of using completely non-compatible cloud products in solutioning situation.

Note: Readers have to know the important caution that is in the form of limitations of the method discussed in this chapter.

1. Unlike Chapter 7 or 9, the method discussed is not a generic one that can be applied to all cloud SaaS solutions that require the use of perfectly non-cloud compatible software products.
2. The above point is true even if some or all the main products are not absolutely cloud compatible.
   

   Figure 8.1  Summary of classes of cases possible in cloud SaaS solution situations using completely non-compatible cloud software products

3. This chapter illustrates a method using a case study.
4. In this case study, only one main product is involved and that is not cloud compatible.
5. The techniques used in this case study and also the tips and tricks adopted in this case study can be used in many similar projects.
6. After sufficient experience, any solution architect will be in a position to provide solutions that he or she encounters. The contents of this book will be of great help to any person to start the journey and also produce simple to medium complex cloud SaaS solutions. Probably, very complex solutions may not be possible directly with the knowledge gained only from this book.
7. Another important aspect that a reader should bear in mind while reading this example is as follows:
   1. The cloud SaaS solution that needs to be architected can be classified into two broad and main categories as follows:
      1. Those that are transactions intensive (see Chapter 9 for brief explanations on additional complexities that these classes of solutions bring in for architecting them).
      2. Those that are transaction-less solutions.

Figure 8.2  Summarizes various classes of solutions possible including transaction-less and transaction-intensive solutions

Figure 8.2 is a modification of Figure 8.1 by incorporating the above two classes, namely transaction-less’ and ‘transaction-intensive’ solutions. Most of the techniques discussed in this chapter will be useful for transaction-less solutions and not for transaction-intensive solutions.

8.3  Some General Strategies

While architecting a solution using completely non-compatible cloud products, some of the following general principles or tricks or tips can be used by architects. Some of these can even become guiding principles for specific projects too:

1. Gather all cloud characteristics and requirements of target cloud SaaS solution. To meet the above requirements, provide separate SBB that is cloud compatible (modules or products), but outside cnc core product(s):
   

   Figure 8.3  User accessing core function only through multi-tenanted customizable portal

   1. For example, consider a situation where cloud SaaS solution has a requirement of a good and highly customizable user interface (UI), but its core product is completely non-cloud compatible, then think of a multi-tenanted highly customizable portal facing users. Figure 8.3 illustrates the solution.
2. Therefore, in architecting procedure (see Chapters 2, 7 and 9), after identifying SBBs, solution architects need to segregate those SBBs that meet the core functionality for which absolutely non-compatible cloud products are mapped and those for which cloud compatible modules are identified. (See Chapter 6 for ‘measuring’ cloud compatibility characteristics of products that become SBBs of the target solution. The same measuring technique can be used to measure cloud compatibility characteristics of target solution too.)
3. For the non-cloud compatible modules or products, identify all the cloud compatible characteristics that are required in the target solution.
4. Create modules that will meet the above (point (ii)) requirements and supplement the cloud compatibility for all those non-compatible SBBs.
5. Probably, architects may need to optimize such supplementing modules by consolidating similar requirements coming from various cnc SBBs into a few common cloud compatibility providing modules.

Therefore, the solution consists of two major identifiable components: (1) Those modules that can handle cloud compatible features, and the same make the overall solution as much as possible nearer to completely cloud compatible. (2) Those core modules that provide core functionalities but are absolutely non-cloud compatible.

Figure 8.4 provides one high-level view of a typical solution architecture, thereby reflecting the above points.

Those non-core functional modules that are make the overall solution more cloud compatible may be mostly custom developed in all the projects. As these common modules that make the solution cloud compatible are very often required for each cloud SaaS solution, it is quite natural for solution architects to look for software products to fulfil these requirements. At the time of writing this book, the author was unaware of such software products. In future, if products do come up, then those will not only decrease the effort of custom developing these modules but also can be a well-tested, defect-free SBBs of the target solution.

Consequently, availability of such software in future and use of the same in solutions will ensure extension of (non-cloud compatible) products’ life without re-architecting to make it absolutely cloud compatible products too!

Figure 8.4  Conceptual view of solution architecture with absolutely cloud non-compatible product

Examining what kind of software products could be non-cloud compatible but still required (urgently – not waiting until it is re-architected to be cloud compatible) is a good proactive exercise for solution architecting team in any typical solution architecting companies that put in use thousands of software products. Typically, they have functionalities that are highly specialized, domain specific and highly custom developed ones.

Therefore, solution architects can even develop a specific architecture for using these cnc software products. Such regularized architecture would have identified solutions for all required cloud compatible features.

Identity and access management could be one component in a cloud SaaS solution, data access modules including multi-tenanted relational DB software could be another, and a portal could be a third one, and these are some examples of modules that will be required for most of cloud SaaS solutions with high cloud compatible characteristics. If workflow is available in the platform itself rather than from a separate product such as in .Net, achieving or providing cloud compatibility characteristics for workflow module may be easy or difficult depending on the provisions available in the platform; it may trivially become easy if the platform itself provides multi-tenancy. (The author is not implying anything on the current capability of .Net; for specific information on .Net capability, please check the respective product manual.) It becomes difficult if the workflow is a separate product within the overall solution. This should be treated like any other product and subjected to analysis of cloud compatibility measures. If it turned out to be a completely non-cloud compatible product, then the treatment is very similar to what has been discussed in this chapter. Similar argument holds good for other components such as business rules engine too.

All the above-discussed SBBs need to be cloud compatible and absorb many of the cloud compatibility requirements of the solution. Even the cloud compatibility characteristics requirement that comes from cnc products need to be absorbed and included in these products. These SBBs can surround the cnc products and apparently even ‘hide’ them from getting exposed to users (or other interfacing systems) directly. Figure 8.4 gives a pictorial view of a typical solution architecture that implements the above discussions.

This will become more clear as the reader goes through the case study presented in this chapter. The common practice at this stage of solution architecting is to expose all the required functionalities from the core software product as service. Sometimes, this is also referred to as ‘service API’. Most of the readers may know API as an abbreviation for application programming interface. Traditionally, product vendors used to provide only APIs that are programming language dependent; and if the API is not available for any particular programming language of choice for the developer, then that will hinder the use of product functionalities in the solution. Service APIs are language independent and provide a loose coupling for integration. Nowadays, product vendors themselves provide these service APIs, which will decrease the workload for solution developers.

These services need to be exposed in the functional layer of a ideal service-oriented architecture (SOA) (or cloud computing reference architecture). See Chapters 9 and 10 for a detailed discussion on this.

The exposed services should be visible only to ‘cloud services creators’ and not to ‘cloud services consumers (or customers)’. (see Chapter 10 for proper definition of service creators and service consumers from cloud computing reference architecture (CCRA) vocabulary.)

Other cloud compatible modules and software products (in the total solution) will consume these services and produce results to users.

With this background, we will understand the case study that uses only one core functional product that is perfectly cnc.

8.4  Case Study

8.4.1  Use Case 1

Set of small and medium banks decided to have a cloud-based solution to facilitate their prospective new customers to open new bank accounts with them.

While signing up for a new bank account, the potential customer may need to supply a lot of supporting documents such as a copy of his or her telephone bill as proof of their mail address, proof of identification such as driver’s license copy, a proof of being in the sate – mostly ration card or voter’s id. Like that, the list of documents to be provided is large and each scanned copy can occupy more than over 5 MB of storage space. (5 MB was the limit in popular cloud SaaS customer relationship management (CRM)).

Until they become customers, it is the banks’ responsibility to hold the proofs and keep them safe. It should be tamperproof for hacking or stealing such information about individuals. Once their application is approved by the bank, then these papers will be once and for all moved to folders within the boundary of the bank. Leaving them on the cloud is not advised as part of banks’ requirements.

In this use case, each bank is a customer for the cloud SaaS solution. Within a bank, there may be many users. Some of them will be internal users or bank employees, and there may be many external users who are potential customers who try to open new bank accounts.

8.4.2  Use Case 2

A catalogue-based product selling company would like to keep a copy of multimedia-based catalogue of the product that every customer selects and orders. This ensures the complete description of the product a customer ordered. It also captures the customization details of the selected product. Even if the company drops that particular product or product line, the details remain in the DB forever. In case of later dispute on the part of customer such as if there is a difference between the ordered product and that delivered to the customer, then this will act as a reference.

The mash up (or multimedia) description of any typical product in the catalogue exceeds 5 MB.

Order entry, tracking sales to delivery is done by a cloud-based popular SaaS CRM system. Due to size limitations of the mash up that can be stored in the CRM, the product descriptions as found in the catalogue cannot be stored along with the purchase order.

Entire product catalogue is stored in a content management system (CMS). The product catalogue itself is a multimedia catalogue and will occupy a lot of storage space.

Individual product descriptions from the catalogue is taken, copied and stored in a separate place in CMS against the purchase order number and a unique identification number to the purchase order.

The URL of the storage location in CMS is embedded back into the purchase order, and the purchase order is saved in CRM as per CRM’s workflow.

Therefore, when the purchase order is retrieved from the CRM for any clarification, using their impeded URL in the purchase order, then one can retrieve the exact catalogue description of the product from CMS.

8.4.3  Some Common Observations

In both the use cases, the end-user or the users of the cloud SaaS solution do not interact with CMS directly.

CMS provides a functionality of storing (and retrieving) a large amount of unstructured data whose size is not a restriction. The data can be in any format such as MP3, MP4, etc. The data are very often referred to as unstructured data in contrast to those that can be stored in relational DB and retrieved through SQLs. The data will be typically comprise voice, video or images or a combination of text too.

In this case study, the CMS is a non-cloud compatible product. This is the one that provides main and core functionality to the solution as discussed in Section 8.4.4.

Refer Chapter 6 for a description of the product and analysis of the non-cloud compatibility of the same product.

8.4.4  Solution Description

1. As indicated earlier in this chapter, all the required functionalities of the CMS need to be exposed as service in the functional layer of the CCRA (or SOA). These services will be visible only to service creators and not visible to service users for both the solutions.
2. Multiple tenants need to be maintained outside the CMS.
3. User management and the privileges of their access rights to various functionalities of the system have to be maintained outside the CMS.
4. While accessing the CMS functionalities, the appropriate access rights that the user may have need to be checked by the other modules before accessing CMS.

   CMS is at the backend, and it will not face users or customers.

5. CMS need to be connected in a trusted mode through the accessing module to rest of the solution. This implies that no users will directly access CMS. In addition, it implies that CMS is aware that only one system will access it, and such an accessing system is trustworthy to transact. Normally, in such situations CMS will be behind a firewall, blocking any other possibility of directly accessing CMS.
6. Any CMS, and especially this one, requires a relational DB as well as a file system. CMS will store multimedia contents in the file system and keep a pointer of the storage in the relational DB. This DB is different from the DB that the solution itself will be having and maintaining one.
7. This pointer along with the row of information maintained in the DB of CMS is passed back to the accessing module. This information is in turn stored in the solutions DB against <customer id>, <user id> and <purchase order number> combination as a key for later retrieval. This information is also passed on to the CRM for it to store it along with the purchase order, and that is the requirement of the system.
8. The solutions DB can be a multi-tenanted model as desired and designed by the solution architect. It can follow any one of the three possible designs indicated in Chapter 5, or it can be any other model suiting to the requirements of the solution.
9. Although the overall solution is cloud-based and multi-tenanted and can concurrently entertain many users, the accessing module will access CMS functionality only one at a time either to store or retrieve the contents (a conceptual view of this is same as that in Figure 8.4).
10. For the use case 2, the CRM itself can provide all the user interfaces. Hence, the required cloud compatible characteristics required at user interface level are left to be provided by the CRM itself. CRM being cloud SaaS, it has the required capabilities naturally.
11. CRM will face and interact with the users directly. Hence, the target solution itself is at the backend and not exposed to users.
12. In use case 2, most of the workflow will be handled by the CRM itself. Similarly, the business rules too. Therefore, the business tier of the cloud SaaS solution that is being architected will be thin and basic, and it need not have separate modules either for workflow or for business rules. CRMs modules for these itself can be extended for this part too. Thus, using the same for both CRM and target solution fits within the general principle of cloud computing to optimize resources and pass on the gain of scale of economy.
13. For use case 2 from the description of requirements and solutions, it looks like that the solution that is being worked out tries to extend the capability of the CRM; CRM has the basic limitation of not able to store over 5 MB of content.
14. In addition, as mentioned earlier, CRM is a cloud SaaS. Salesforce.com™ is one such example of a CRM existing on the cloud. The target solution is also conceived as cloud SaaS.
    1. Solution also can reside on the same Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) platform as that of CRM (see Figure 8.5 ). For example, Salesforce.com™ provides one such platform having IaaS and PaaS for both developing as well as launching the solution. Incidentally, Salesforce.com™ is a cloud SaaS CRM in the cloud.
       

       Figure 8.5  Both CMS solution and CRM reside and share the same IaaS and PaaS platform

       

       Figure 8.6  CMS solution is offered from a public IaaS cloud, which is different and away from CRM cloud

    2. Such an approach of both CRM and CMS solutions being in the same IaaS + PaaS platform offers a lot of benefits: One such benefit is that the data transfer between them is secure, faster, and the size (of content data to be passed to CMS solution) does not matter. Since IaaS and PaaS platform is shared between them, the cost will be lower.
    3. Alternatively, the CMS solution can reside in a separate public IaaS cloud. Since the CRM is also in its own cloud, one can clearly see that the two clouds – CMS solutions cloud and the CRM cloud – will exchange data between them (see Figure 8.6).
       1. In that situation, high security has to be provided for the connection between the two clouds to securely exchange data.
       2. The data also need to be protected during the user (flight) transmission on this connection.
       3. Service interfaces are not really a suitable mechanism for exchanging high-volume data, such as multi-media content, through them^{[ 10– 12]}.

Use case 1

1. For the use case 1, the solution needs to provide an exclusive Web tier, and all multi-tenanted user interface facility.
2. The business tier needs to have separate business rules engine and business process systems in order to meet the requirements.
3. Data tier will be very similar to the one described earlier for use case 2.
4. In reality, the entire solution needs to be architected as cloud SaaS with all cloud compatible features, except for the core functions coming from complete cnc product. But the functions from complete cnc product will be made available to end-users from the rest of the modules of the solution in a true cloud SaaS solution characteristics.
5. On exposing all the functionalities of CMS, this becomes a generic cloud SaaS solution for any enterprise to have a content management solution. Such a solution is ideal for small- and medium-sized enterprises. SpringCM™ is one such cloud SaaS solution for enterprise content management. However, SpringCM™ is built from scratch as true cloud SaaS with all possible required cloud characteristics to serve multi-tenants and (not having embedded cnc CMS) as the solution.

8.5  Summary

• This chapter has illustrated architecting cloud SaaS solution using completely non-compatible cloud product.
• A brief discussion is provided about various classes of solutions involving completely non-compatible cloud products.
• The general points that may be useful for most of similar projects is summarized and discussed in the beginning of this chapter.
• One particular solution is illustrated using two use cases; but, both the use cases need to use a CMS that is not cloud compatible at all. (Although there are cloud compatible products in this class, project situation forced to choose the cnc product.)