Chapter 1

Introduction

This chapter explains the title of this book and also introduces various basics that are necessary to understand concepts and body of knowledge dealt with in this book.

The acronym SaaS stands for software as a service. The concept of providing SaaS is not new. Although it has been less popular in the past several decades, software has been provided as a service by various means. The most popular one was a hosted model in 1990s. It has evolved over a period of time and now software can be deployed and provided from ‘cloud’. However, this is a service provider’s viewpoint. From service consumers’ viewpoint, customers enjoy these services through public Internet, using thin clients such as Web browsers on desktops or mobile devices.

1.1  SaaS Deployed and Provided from Cloud Environment

Cloud computing reference architecture document proposed by IBM^TM to The Open Group Architecture Framework (TOGAF) has the following definition and explanation:

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings^[24].

SaaS is also referred to as applications as a service because SaaS is essentially about providing applications as a service (as opposed to software in general). This also includes content services (e.g. video-on-demand) and higher value network services (e.g. VoIP) as typically encountered in communication service provider scenarios^[37].

“Software-as-a-Service (SaaS)^[37] shares the distinction of being both a business model and an application delivery model. SaaS enables customers to utilize an application on a pay-as-you-go basis and eliminates the need to install and run the application on the customer’s own hardware”.

Using above statements, we can settle for a simpler definition: SaaS can be roughly defined as software deployed on cloud, provided from or through cloud and also being consumed by accessing these services through cloud. The cloud here refers to the Internet.

SaaS through cloud has:

1. A new method to provide software, which has otherwise been provided in compact disk or memory stick.
2. A new business model for software providers on a ‘pay-per-use’ mode rather than one-time buying of license for each copy being used.
3. SaaS has begun to open a new market segment for software; otherwise is confined to use by large enterprises with heavy IT use.

Architecting a solution or software that would address these paradigms has resulted in a whole new body of knowledge in itself. Before looking at concepts to architect SaaS for the cloud, it is important to understand these three areas.

From software provider’s perspective, SaaS (deployed and provided through cloud) supports many customers from a single instance. This new ability of serving many customers from single instance of software is referred to as ‘multi-tenancy’. This demands a new architecting approach for tackling requirements such as multi-tenant customization and extensibility, data scaling and isolation.

Challenges such as ‘scaling’ have disappeared due to new technique that cloud brings in, namely ‘auto-scaling’. ‘Scaling’ refers to an attribute of a software that it can accommodate more number of users when deployed and running in production, actually even unexpected or unplanned number of users, without requiring to modify or re-write the software.

Architecting for ‘auto-scaling’ comes with its own challenges:

1. The scalability issue has been addressed differently, before cloud computing could arrive, through the following technique: scaled either vertically (by more processors or main memories) or horizontally (by adding additional servers working in parallel).
2. But cloud computing made automatic allocation of additional processing powers on the fly, while the instance is running and serving in the production, without bringing down servers or waiting for procurement lead times. This is in nutshell ‘auto-scaling’.

Customers pay as they use it, in contrast to buying a copy of a software through a license agreement. In this sense, business model for providing SaaS through cloud has also changed.

Such a change lowered the cost of software, which otherwise remained as costly investment, and affordable only by large enterprises. With pay-per-use model, even small enterprises with very thin IT budgets can consume these services. Hence, these – named ‘long tail’^[5] – become a new market segment for SaaS providers.

1.2  Software Solution

A software solution refers to certain business capabilities (or helps in achieving certain business capabilities) that are possible because of an intended software.

By ‘cloud software solutions or products’, this book consistently refers to the ‘line-of-business services’ offered to enterprises of all sizes. ‘Line-of-business services’ are often large, customizable business software solutions aimed at facilitating business processes such as customer relationship management, enterprise resources planning system, enterprise content management system, costing, accounting and finance. In cloud SaaS, these services are typically sold to customers on a subscription basis^[5].

Architecting software solutions has two different connotations in software system integrators industry, and these are as follows:

1. First is in pre-sales situation for obtaining sponsors’ acceptance.
2. Second is after the project is fully approved and given a go-ahead.

Before obtaining a formal approval to develop a solution, software solution is architected to provide an idea of what the intended solution would be with minimal essential details of the solution.

After obtaining formal approval and sponsorship to develop solution, a detailed architecture will be created. This is the (second) context in which contents of this book provide a body of knowledge required for architecting, especially for cloud SaaS software solutions or products.

A general method of architecting software solutions can be found in enterprise architecture benchmarks promoted by TOGAF^[4]. This general method is also applicable to architecting SaaS solutions or products in the cloud.

This generic method has been customized and adopted by the author in various cloud-related projects. The customization attracts a special interest when architecting solutions for a variety of companies, small or medium enterprises (SMEs) in particular. Chapter 2 in this book elaborates these points.

Technical aspects of solution architecting have grown by leaps and bounds in the past two decades, but the growth rate appeared to have slowed down till cloud computing emerged to take centre stage. Architects have developed reference architectures, blue prints, domain architectures, architectural patterns, etc. Thus, templated architecture and best practices in architecture have been well documented, for reducing challenges to solution architects.

Architects need to customize these ideal architectures to provide a solution to their specific business need. But architecting SaaS for cloud demanded many new concepts to evolve to support many new attributes (or characteristics of software) such as multi-tenant customization and extensibility, metering, auto-scaling, data scaling and isolation. Thus, SaaS through cloud (or cloud SaaS as it is used in this book) expanded the field of architecting software. This book mainly covers this additional knowledge.

The primary role of solution architects’ is to provide a software system that addresses business requirements as solution^[4]. Architects conceive solution in their mind before communicating the same to others. A typical civil engineering architect will construct a physical model of the envisaged building to communicate what he/she conceived in his or her mind as solution. However, for software solution architects constructing physical model is not always possible. However, software solution architects can communicate their envisaged system through a series of views of the envisaged system.

Reference [6] is an international level to describe software architecture and possible views of that can be used to describe an architecture.

1.3  ‘Software Architecting’ is Different from ‘Software Designing’

Architecting software solution, as found in the title of this book, means designing software solution. This book uses a newly coined term, ‘architecting’, to bring to the attention of readers that architects do a lot of things different from software ‘designers’.

Architecting = developing architecture

The English language provides a verb ‘design’ for the actions of architects. Unfortunately, the same verb is also used for actions of designers. Therefore, the use of the verb ‘designing’ leaves an inherent ambiguity of who is ‘subject’ of the verb – architect or designer? To eliminate this ambiguity, this book proposes to use two different verbs: architecting and designing to unambiguously refer to actions being carried out by architect and designer, respectively.

In computer, software development life cycle, role and deliverable of architects are totally different from that of designers.

Knowledge required to architect software products or solutions is now vast, and requires a deep specialization, different from that of designing software. Designing is the next step to architecting, and architecting is the first step which conceives the solution and provides its detail at a very high level (top level).

Architecting is a process by which architects visualize and arrive at a set of ‘building blocks’ that will make up the software solution. Visualizing and specifying interactions and connections between these ‘building blocks’ are also a deliverable and part of architecting work.

Specifying an architecture of a solution by its constituting architecture building blocks (ABBs) and their interaction is considered as one of many possible views of the solution. For guidelines on other possible views, readers are referred to Ref. [6].

1.4  TOGAF, ABBs, SBBs and Building Blocks

Building blocks that make up an architecture, referred to as ABB, are a collection of systems’ functionalities that the software will eventually provide^[4]. Subsequently, each ABB will be implemented as one or more (functional) module(s) of that software (product or solution).

ABB is a basic term defined and explained in the global enterprise architecture levels promoted by TOGAF^[4]. The guidelines have defined and explained many such terms and benchmarked the language for architects to consistently communicate among themselves. This book adopts, follows and uses the language, acronyms, taxonomy and vocabulary that have been idealized and promoted by TOGAF.

Solution building blocks (Sbbs)

The software modules (or software products) that realize ABB are said to be solution building blocks (SBBs), as per TOGAF’s definition^[4]. One or many software modules or products will realize one or more ABBs

There are several ways of developing or implementing software solutions.

As most readers may know, a bespoke solution or tailor-made solution is most popularly also known as ‘custom-built solution’. A software, built specifically to serve a single enterprise usage, is what is alternatively referred to as a custom solution. The cost of such a solution is pretty high.

Only a few organizations can afford such a solution. Although such an approach is required to meet certain highly specific business objectives, software-developing vendors realized that the cost of such an approach is also high. They then began to build generic software that can be customized with less effort and cost to meet individual corporations need. Such a generic solution is built once, and copies are sold to many client enterprises. The term ‘COTS’, commercial off-the-shelf products, is used to refer to these software products.

Community of software professionals felt that the cost of COTS is exorbitantly high. Hence, out of interest and voluntary effort, software professionals began to develop products parallel to each and almost every possible COTS products. This community of software professionals even made source code of these products available to customers. Hence, these are also referred to ‘open-source’ products. Therefore, we have two kinds of products: one is referred to as COTS and the other is referred to as ‘open source’. In general, the cost of ‘open-source’ software products is less than that of COTS.

To provide a complete solution, architects may have to choose one or more software products – be it open source or COTS. In addition to these, some more software modules need to be custom-developed to cover functionalities that are not covered by the selected software products.

A bunch of functionalities in COTS or open-source products or custom developed code meeting functionalities of one or some of ABBs is referred to as SBBs as per TOGAF’s terminology^[4].

Software products that become part of any cloud SaaS solution also need to possess certain special characteristics. This book describes these characteristics as part of what is defined as ‘cloud compatibility’ in Chapter 5.

For architecting cloud SaaS solution, all components that make-up a solution, namely, be it COTS or open-source products or custom module (in nutshell all SBBs) should also be desirably ‘100 per cent cloud compatible’.

In reality, many of the available software products are not yet absolutely cloud compatible. Some of them are partially cloud compatible and some of them are fully not cloud compatible. Hence, architects need to face a situation to architect solutions with a various combinations of cloud compatible or non-compatible.

This book shows how to engineer (architect) software solutions that can serve as cloud SaaS from the cloud computing environment and accessible through the cloud:

1. Using perfectly cloud compatible software products.
2. Using semi-cloud compatible software products – (Chapter 7 is devoted to this topic).
3. Using software products that are not cloud compatible – (Chapter 8 is devoted for this topic).
4. In addition, this book also shows how to engineer completely cloud compatible software products – (Chapter 9 is devoted for this topic).

Readers can figure out from the knowledge gained through this book, how to re-engineer and re-architect existing non-cloud compatible products into a cloud compatible one.

If software products become cloud compatible, then architecting a solution will become much easier, natural and cheaper too. This drives home a point: that there is a need to have an engineering method to take cloud not compatible software products and re-engineer them to make them more cloud compatible products. Information found in Chapter 9 can be used for this purpose of re-engineering an existing product to make it more cloud compatible.

Some of the principles discussed in Chapter 9 can also be used to engineer (architect) even ‘custom code’ that may be necessary to complete any solution so that the resultant solution will be a good cloud compatible SaaS solution.

1.5  Cloud SaaS – An Evolution and SaaS Business Models

This section will review how cloud SaaS has evolved over a period of time. As and when the technology has been developing and getting adopted, the associated business model also has been undergoing a change.

Business model refers how service providers have been charging their customers for their services. Business models vary from model to model as explained here. This is also intermingled with what kind of organizations that can afford those prices.

This section will also review various business models in chronological order of evolution from ‘mainframe leasing’ days to now in cloud SaaS time.

1.5.1  Mainframe Leasing Model

In 1960s and 1970, mainframes were leased out rather than being sold. The common argument given by many mainframe manufacturers of those times was that the intellectual property cost was so high that the mainframe computing machines could not be sold because of prohibiting high cost, and hence it could not be bought. Therefore, it could only be leased out.

1. Leasing customers paid a fee for the time of CPU, memory, storage and other peripheral devices utilized on a monthly basis. Cost per time for each of these units varied with CPU time being the highest. (Today most of public cloud infrastructure as a service uses a similar pricing model for charging their customers who are using their hardware platform.)
2. The use of their infrastructure software such as compilers, editors, etc. were charged on pay-as-per-use basis in proportion to the time used.
3. Mainframe providers (leasers) provided for a fee professional service to develop ‘custom software’ to meet the business requirements that it should serve. However, this software could not be utilized by other organizations as these are custom developed to serve one organization’s specific requirements. The cost of professional services was also on ‘pay-per-use’ model though that term ‘pay-per-use’ was absent then.
4. Also professionals’ costs needed to be paid to maintain the ‘custom software’. In reality, this was an on-going expense as long as the software was in use.

The above elements of cost structure predominantly exist even today in the SaaS-through-cloud pricing model.

Cloud SaaS model reduces costs in each of those components mentioned earlier; this is possible because costs are shared among all customers^[5]. Uses a term called ‘economy of scale’ to denote cost reduction on sharing among customers in the cloud model.

1.5.2  Conventional, on-Premise Installed Model

Many readers may be familiar with a traditional practice of buying software and installing it in their machines on-premise before using it.

In this scenario, software-manufacturing (or publishing) companies provide a copy of software in a suitable media such as a compact disk. Software is sold as a product and bought by customers as a product. Once customers buy software (solutions) as a product, they have every right to do whatever they want with the product (of course as permitted by the license). Please note the use of word ‘product’ (and not yet ‘service’).

1.5.3  Hosted Model of 1990s

By this time, software products began to emerge. Instead of custom developing same or similar application solution for each customer, vendors realized one software product could be developed and a copy can be sold to each customer enterprise. Such an attempt helped reduce software solution development cost.

Since these products provided a facility for customization, the cost of item 3 in sub-section 1.5.1 came down.

Thus, two cost elements were low compared with costs in ‘mainframe leasing model’.

Hosted model providers implement these solutions in a data centre (which is away from the enterprises’ boundaries) in hardware (and infrastructure software) dedicated for each of their customers. Therefore, this cost element came straight on customers for whom these are dedicated to.

Installation, customization of solution and subsequent maintenance are part of providers’ responsibility. Some of the providers are optimally using this team of professionals across customers and that brings the cost down compared with dedicated team.

Some of the hosted solution service providers optimized cost of maintenance professionals by optimally sharing those resources across customers. This is the third cost element, which is lower compared to ‘mainframe leasing model’ (see sub-section 1.5.1) where the professional resources were also dedicated.

This was a very significant step in SaaS evolution. This was the first time that customers could get their SaaS. They did not have to go into the technical details of implementing or customizing or maintaining their dedicated solution. Thus, client enterprises transferred IT responsibilities to the hosted service provider. (Most of these aspects are retained in modern-day cloud SaaS providers, and cloud SaaS consumers enjoy the same).

In this scenario, customers need not worry about the following key parameters: (1) customers need not have their own hardware on which (SaaS and infrastructure) software need to be installed. (2) They need not worry about tasks related to installation, maintenance and upgrades of software.

Customers will pay a fee for use of the hosted software. In this model, customers do not see even the computer centre wherein the software is implemented. They just make use of the software to get a useful output for their business.

For example, if the software is for payroll processing, customers will get their employees’ pay cheques printed out. It is equivalent to having an accountant get the payroll processed and write pay cheques for employees. Therefore, the accountant provided the service of calculating pay amount and writing pay cheques.

Here, software is provided as a service and customers can consume it as a service. Customers pay for the service used to that extent. They do not own unlike in buying software products where they at least own copies of software products they bought.

The advantages of this model are listed below:

1. For the first time, customers got a complete solution for their IT need. Hardware, software and maintenance required including managing IT environment was completely outsourced (from service consumers’ viewpoint).
2. In this model, facility is dedicated to each customer, although it is outside customers’ premises.
3. Since it is dedicated, it is expected to have data security and privacy.
4. Client enterprises clearly know the total cost of utilizing these services.
5. Each client can ask for their own customization of software and solutions to meet their business needs.

The disadvantage of this model is that similar to the ‘mainframe leasing model’, the cost of providing service is high in this model too (compared to the cloud SaaS model), since the facility is dedicated to each customer (and not shared across all customers as in cloud SaaS model).

1.5.4  Cloud Model: (SaaS Provided from Cloud Environment)

Software can be provided as a service from cloud environment too. This book focuses only on such a situation.

SaaS provided from cloud has a lot of additional advantages over the other models described. It can be considered as logical improvement over the ‘hosted model’.

Infrastructure hardware and software is not dedicated to each customer. It is one single shared infrastructure across all customers. Unutilized hardware capacity is effectively put into use for other customers’ demand who may be using the same. Similarly, all other resources such as network cost, data centre cost and hardware maintenance professional’s costs are also shared among all customers, and hence the operation cost is optimized for its use, which is the essence of ‘economy of scale’.

Customers are charged on a pay-per-use basis. This opened a new market of small time users whose total market size is bigger than dedicated solutions’ consumers^[34], which is explained later.

Enterprises can customize SaaS solution. (On one single copy per every customer, customers can customize their own copy.) Thus, the advantage of customizable products is provided in cloud SaaS model too. But the task of customization is left to the customers in cloud SaaS model unlike the other models. Many organizations would also like to use off-the-shelf services of the solution rather than customizing it heavily. SMEs prefer this for both convenience and cost saving. Some of the small time users do not customize them at all.

Software upgrades and system maintenance are done by cloud SaaS providers, and the professional services required for maintenance are shared across all users. This way the cost comes down to each customer (compared to other models).

1.6  SaaS Provided from Cloud Environment vs Hosted Model

The following section compares and contrasts ‘hosted model’ to ‘cloud model’ of providing Software as a Service.

Service providers’ view	Cloud SaaS model	Hosted model of 1990s
Service provider to service consumer relation	One service provider provides one single copy of solution software as service, but many customers use the same instance.	One service provider; For each customer, a dedicated facility – hardware or software or solution copy – is provided.
Location of providing service	SaaS can be provided within enterprise boundary or outside enterprise.	SaaS can be provided typically from providers own data centre outside enterprise boundary.
Infrastructure hardware as per deployment architecture.	Deployment architecture is horizontally scalable or scale out to support any number of customers.  Infrastructure is transparent to customers, and its cost is shared among all customers and rolled into price of service.  Therefore, the cost comes down.	One set of hardware corresponding to deployment architecture is provided for each customer separately.
Infrastructure software such as O/S, app servers, Web servers, etc.	One license will serve and support all customers.  Infrastructure is transparent to customers, and its cost is shared among all customers and rolled into price of service.  Therefore, the cost comes down.
Application software or solution software	There is only one installed copy (one instance) of the software solution that simultaneously serves many customers.	In hosted model, for each customer, one copy of the software is installed; this means that if there are 100 customers who are availing the software as a service, then there will be 100 copies running in the service provider’s data centre.
Customer data	It depends on the data model: it can either be in a dedicated database or may lie along with other customers’ data in the same database.	It is a dedicated database, and hence there is complete isolation of one customer’s data from others.
Software upgrade procedure.	In the cloud model, since there is only one version running, it will be upgraded, and it is so easy. Hence, the cost of maintaining the software is low. However, running version will not be stopped for the purpose of upgrade.	In the hosted model, every one of the several installed software will be separately upgraded.
Business model	Consumers pay a price in proportion to their usage of the software services.	This is a fixed monthly fees, and this is not in proportion to the usage of the software.
Who owns the software?	Customers do not own anything in providers’ boundary.	Since dedicated facility is mostly built using customers’ money, it belongs to them.
Who is responsible for the functionalities or business capabilities that the solution addresses?	Cloud SaaS provider or the software product vendor.	Provider is not responsible at all.
Who is responsible for managing facilities? – h/w, s/w, version upgrades, bug fixing in software.	It is the responsibility of the service provider.	The service provider will apply patches, upgrade software, etc., but for a fee.
Service consumers’ viewpoint
Customizing software	Customers are responsible for customizing.	Customers are responsible for customizing.
Managing user accounts	Customers are responsible for managing user accounts and providing access rights.	Customers are responsible for managing user accounts and providing access rights.

1.7  Enterprise Models for SaaS Consumption

When the software product is provided for on-premise (or a hosted model of 1990s), the implications to the vendor are different as compared to cloud SaaS service providers. Solution architects need to understand the group or class of industries to which the solution is provided as service.

In mainframe times, only a few enterprises could afford to use these technology-based solutions. Productizing software made many enterprises affordable to buy these products. Cloud SaaS opens many more possibilities such as SMEs or very small time to afford IT consumers also to consume these services. The same is explained further.

This section discusses three types of enterprises: First is large enterprises; second is a group of enterprises or a community of enterprises comprising a large number of very SMEs; and third is referred as ‘long tail’ pointing to very large number of small time users of these services.

Understanding these three types of consuming enterprises is essential for architecting solution to them (be it cloud SaaS or otherwise too).

1.7.1  Modelling Enterprises (for the Sake of Providing Solutions)

While architecting cloud SaaS solutions or products, architects need to reflect the characteristics of enterprises nature in the solution or product.

Any enterprise characteristics can be described through an enterprise model referred to as an enterprise architecture^{[9, 35]}.

Zaachman’s model of enterprise architecture is given in Ref. [35].

The diagram in Ref. ^[35] indicates that enterprises can differ from one another by at least 36 parameters.

For example, enterprises might have organized themselves based on type of products or services they offer to their customers. Some enterprises may organize themselves based on the countries, regions and continents on which they operate. Some enterprises may have a predominant organization structure based on their internal functions such as main product or service delivery department, HR department, legal department and other support departments.

The above paragraph indicates that there are at least two possible values for one parameter, namely, organization structure. If we assume 10 possibilities for each of the 36 parameters, then the total numbers of combinations available is 36 to the power of 10. This analysis indicates that there are a wide range of enterprise models possible, and they exist out in the world.

Business rules, business processes, organizational structure, etc., of an enterprise may need to reflect in the software to be able to use solution software correctly.

Obviously, entertaining all these 36 power 10 (36¹⁰) variations in a single software is not practical.

1.7.2  Bigger Enterprises and Verticals

Enterprises being grouped segment wise, such as Telco’s (telecommunication service providers) or retail or health care, reduces solution complexity to a major extent due to likely similarities among enterprises in the same segment. Software products are being developed, which are industry- and solution-specific ones. As discussed earlier, the cost of development decreases if the solution software is industry segment specific, but the product vendors need to make their money by selling copies of the solution software.

Sometimes, a single software (product or solution) alone may not address all the business requirements of an enterprise even though the enterprise is within the industry segment for which the product is aimed at. Hence, software solutions are being developed using software products bound with a few custom-specific codes too. Or the software product is customized as the software product would allow matching the practices of individual enterprises.

Hence, industry-specific software solutions need to address only a limited number of possible variations in the 36 parameters modelling enterprises.

Typically, the cost of these solutions can be afforded only by a few large enterprises that have larger IT budgets and referred to as ‘addressable market’ in Figure 1.1^[5].

1.7.3  Small- and Medium-sized Enterprises

As cloud SaaS solutions could bring down the cost of providing these solutions, the same solution can also be used by other industry segments whose IT budgets are relatively lower. SMEs are one such example.

Cloud SaaS solutions are built also to serve a community of SMEs such as textile manufacturers or automobile spare parts manufacturers (this is quite true for Ref. [1]). In the North and South Carolina States of the United States, there are about 300–400 small or medium wooden furniture manufacturers whose typical revenue will be of the order of 10 million US dollars or less. Each enterprise in this community may not have a very elaborate enterprise architecture as discussed in the earlier section. Enterprises in SME segments are simple and have simplest possible enterprises architecture, but never have a documented one. However, some small enterprise would like to differentiate itself from the remaining competitors in the community.

Individual enterprises may be trivially simpler, but a community of them may demand a wide range of possibilities in enterprises model to be accommodated in the SaaS cloud solutions.

In reality, there is need to architect a software that will accommodate all the possibilities of enterprises variations as mentioned in the type ‘larger enterprises’ if the software is also meant for SMEs.

1.7.4  Long Tail

This can be considered as a special case too. These are a large number of enterprises that consume lower amount of IT services and products. Their total revenue may be small enough to prevent them to go for any dedicated on-premise implementation of any line-of-business software solutions. The IT budgets that they can afford may be very small compared to big enterprises that can afford to have dedicated custom solutions to run within their enterprise boundaries. It may be even smaller than the SMEs segment. Probably, they will not even have any specified IT budget. They can preferably use it one time or as and when required and pay only for it rather than having any upfront capital investment or captive IT facility serving them dedicatedly.

Although they are small time users, they may have a very similar need among themselves unlike SMEs of special class discussed earlier, and also they may essentially from the same vertical such as Telco’s, or retail or manufacturing, etc.

As cloud SaaS solutions can support the business model of pay-per-use, these small time IT consumers can also use cloud SaaS solutions.

As discussed in Ref. [36], there are a large number of such small time users out in the market.

Also Ref. [34] indicates the size of such market is enormous.

The success of Amazon^TM (the online book seller) helps in confirming the same. Conventional bookstores need to have enough space to store book titles that customers are most likely to buy. In this model, the space of the store will put a limitation to the number of titles it can store on-display. But Amazon^TM has a catalogue, and books need not be stored in any one single physical place. It can be kept even in publishers’/printers’ place or warehouse. On getting the order, Amazon^TM can give instruction to ship the book from the publishers’/printers’ warehouse to customers’ address. This way all books in print can be in the catalogue, and there is no inventory holding cost for Amazon^TM.

Similarly, titles less popular that are bought by one-off users are large in number, and this is the one that contributes to a large percentage of sales.

The customers who buy low volume of products but who are large in number out there in the market are referred to as ‘long tail’. This market segment is also known by the same name as ‘long tail’.

Reference [5] explains how this is applicable to software products market. Figures 1.1 and 1.2 show revenue per customer on the y-axis and the number of customers who can spend that much on the x-axis.

In mainframe leasing model or conventional on-premise installed model or 1990s hosted model, the cost of providing service was so high (as indicated by dotted line that runs parallel to x-axis in Figure 1.1). Hence, ‘addressable market’ that could avail these services was limited to a few number of larger enterprises. Consequently, the ‘addressable market’ size was relatively smaller. The non-addressable market includes ‘long tail’.

Compare cost of services indicated by dotted lines in Figures 1.1 and 1.2. Due to economy of scale in cloud SaaS model, the cost has got lowered as in Figure 1.2. Hence previous non-addressable market could now become addressable.

Figure 1.1  Non-addressable market due to higher cost-of-providing software ^[5]

Figure 1.2  New market opened by lower cost of cloud SaaS ^[5]

This is an untapped new market for cloud SaaS solution providers. This is a huge market, and hence business potential is huge. Cloud SaaS solution is a successful attempt to bring down the cost of providing software services, and hence it addresses this long-tail market.

1.8  Summary

• This chapter introduces and explains the title of this book.
• It also provides context for the subject matter covered in this book.
• SaaS is roughly defined as software deployed on cloud, provided from or through cloud and also being consumed by accessing these services through cloud.
• Most commonly and loosely used terms such as ‘software solution’ are explained to carry the same meaning throughout this book.
• TOGAF’s basic terminologies and the language elements are taken as the base language for communicating architectural ideas discussed in this book.
• This chapter traces evolution of cloud SaaS through ages from mainframe leasing model through hosted model of 1990s. The evolution of business models of providing these services is also traced.
• Enterprise modelling is essential for architecting cloud SaaS solution, and the same is introduced.
• Lowering cost of providing services thorough ‘economy of scale’ by cloud SaaS has made even to SMEs, as well as ‘long tail’ of small time users afford information technology for enhancing their business capabilities too.