In the last decade IT industry focused on the transformation of software delivery from process-based to service-based. Since then, the evolution in this field was enormous: Software Oriented Architecture (SOA) and its implementation on Enterprise Service Bus (ESB) solutions, virtualization on several layers including infrastructure (IaaS), platforms (PaaS) and software (SaaS).

SaaS or “Software as a Service” is the software that is deployed over the internet and/or is deployed to run behind a firewall on a local area network or personal computer. The SaaS delivery model imposes new architectural principles to the software its self. Each software application ready to be delivered as SaaS must be compliant with specific architectural principles in order to take advantage of the SaaS model. The following major features characterize software as a SaaS architecturally compliant one:

• Multitenancy: refers to a principle in software architecture where a single instance of the software runs on a system infrastructure, most of the times on a virtualized infrastructure, serving multiple business domains (tenants). With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each business domain (tenant) works with a customized virtual application[4]. Multitenancy is the fundamental architectural pattern of SaaS and thanks to this feature SaaS delivery model introduces significant cost savings and allows the applicability of long tail business policies to the software. On the other side multitenancy introduces significant complexity to the software architecture because it affects profoundly presentation, business logic and data layer.
• Business Support Services for SaaS: refers to the systemic components that a software service provider uses to run business operations of software service towards business domains (tenants). Major business support services in SaaS ecosystem, consider: tenant management & activation, software service request management, software service catalog and software usage rating & billing
• Operational Support Services for SaaS: refers to the systemic components that a software service provider uses to support software service operations & management. Major operational support services in SaaS ecosystem consider: software service fulfillment and provisioning, software service delivery, software service assurance and software inventory & management.
• Software-oriented Architecture: refers to the ability of SaaS ecosystem to define software as a business object by using software metadata as software entity’s attributes. This architectural principle is prerequisite for the business and operational support of the software service as for example software service catalog or software inventory.
• Tenant-centric Architecture: refers to the efficiency of SaaS ecosystem to consume and exploit tenant related metadata along with application data and functionalities. This architectural principle traverses entire SaaS ecosystem and affects multitenancy and support services.
• Single Workspace from Anywhere: A SaaS runtime environment should be accessed through Cloud from a single point for all tenants and for all provided software services. This architectural characteristic facilitates features such as SSO & authentication, authorization, customization & profiling for each tenant. Structural element of this architectural approach is the service container, responsible to consume at runtime appropriate tenant-centric metadata and deliver respected software service to the user of the business domain.
• Virtualization Interfacing: The infrastructure that supports a SaaS deployment must be shaped accordingly the demand of the software either dynamically at runtime either statically at configuration time based on predefined profiles. This architectural feature requires a bidirectional interfacing with virtualized hardware infrastructures capable to manage requests for infrastructural resources allocation and release.
• Enhanced Security: SaaS environments are expected to provide adequate levels of security and robustness not only at physical or system level but also at logical level combining tenant-aware characteristics. Enhanced security includes SSO and identity management, tenant aware processing and data isolation. Logical security involves advanced audit/trail mechanisms, fraud detection, virtual execution and encapsulation per tenant etc

who is in SaaS

SaaS delivery model major stakeholders:

• tenants: organizations or individuals that consume SaaS functionality over the Cloud
  • From the perspective of service provider, tenant considers the customer that consumes SaaS.
  • From the perspective of software vendor, tenant considers the business domain that uses the software.
• service providers (SP): organizations that deliver SaaS functionality over the Cloud to their customers
  • An SP has profound business knowledge, developed retail network and sophisticated technical infrastructure to deliver services to its customer base. The most well known realization of service provider is the communications service provider (CSP) which is the most mature in terms of service delivery and support in order to provide SaaS.
• software vendors (ISV): businesses or individuals that design, develop and sell software functionality
  • An ISV owns a software portfolio and the respected know-how regarding the provided functionality of this portfolio.
  • From the perspective of service provider, an ISV considers a third-party supplier of the required software resources for the SaaS delivery and fulfillment.

Other stakeholders, who can interact with the SaaS delivery model in a passive way, are:

• system integrators (SI): companies or individuals that specialize in bringing together component subsystems into a whole and ensuring that those subsystems function together.
  • An SI participates and delivers SaaS-driven projects
  • From the perspective of service provider, an SI considers as a third-party supplier who can integrate several components in order to function the required business and operational support services for the SaaS.
  • From the perspective of ISV, an SI considers as a third-party supplier who can delegate and implements the required SaaS transformation of the software.
• infrastructure providers (InfraP):organizations that deliver infrastructure over the Cloud to their customers.
  • From the perspective of service provider, an InfraP consider a third-party supplier of the required infrastructure resources for the SaaS delivery and fulfillment.
  • Certain types of InfraP, such as IaaS and PaaS providers, could offer SaaS by extending its core business by taking advantage of his existing service delivery expertise and Cloud infrastructure.

SaaS model advantages

The SaaS model is followed by several advantages both for the tenant, e.g. business domain, of the application and the application provider.

From tenant perspective, these advantages are:

• Less software costs: The customer is not obliged to pay in advance the total cost of the software; instead he pays only a fixed and/or pay-per-use fee according to his real needs
• Less hardware costs: The customer isn’t required to obtain a costly hardware assembly in order to support the operation and the management of the application; the only required equipment is a set of workstations with Web access
• Less operational costs: The customer reduces his operational costs including supported infrastructure (backup, monitoring, access control, security etc), location and administration. Simultaneously power consumption and cooling costs are significantly decreased constituting the organization environmentally friendlier.
• Less specialized personnel costs: SaaS eliminates the requirement of specialized and, in most cases, expensive personnel for the administration, monitoring and versioning of the system. As a result a major cost reduction including payroll, training and personnel administration takes place.
• Access to the system from anywhere at any time: The end-user or his authorized business partners only needs an Internet connection in order to access the system from anywhere at any time.

From the perspective of the software provider these advantages are:

• Perspective of a steadily increasing income: Thanks to subscription and/or usage model, the software vendor has a steady monthly and/or yearly income and the ability to increase his revenues beside the EULA model.
• Access to the worldwide market: The software vendor has the opportunity to address a vast market thanks to the SaaS commercial model (Long Tail business model) and the access to his software from anywhere through Internet.
• Less operational costs: The software vendor reduces or eliminates several operational costs including change management, account management, complex commercial policies etc.

Stakeholders challenges & the role of SaaS

The most common architecture for software systems available since early the decade of 2000 constituted the so-called "on-premises software" or "on-prem software" in which the software is installed and operated in the headquarters (on-premises) of the person, company or organization or general business domain which uses it (ref: en.wikipedia.org/wiki/On-premise software). The key feature of this approach is that the software manufacturer (software vendor) undertakes the construction and promotion of the software and the organization which uses the software undertakes its acquisition and operation as well as the resources and infrastructure to support this facility.

The"on-premises software" distribution model was shown to have significant issues for the organization which concern:

• acquisition costs: The proportional cost per organization becomes high because the overall software deployments are limited mainly due to the product distribution while increasing the required supporting hardware and peripherals.
• operating and maintenance costs: The operating and maintenance costs of the installed solution per organization burden the organization which is very expensive since it involves systemic and human resources. Actually, this increases depending on the degree of complexity and automation of business functions covered by the software application.
• high degree of specialization: The maintenance and operation of a software installation require highly specialized staff whose absence can cause outages on parts or all the organization.
• availability& extensibility: The continuous operation of a software installation is the result of complex processes and significant investment in relation to the degree of complexity and automation of operational functions covered by the software. The same happens with extensions of functionality or of the infrastructure of a software installation. Possible disruptions in the availability and extensions of a software installation cause major problems to the organization.

With the advent of the widespread use of the Internet and advanced navigation technologies (browsers) and given the above disruptions, alternative models of distribution and use of software were presented. The most characteristic is the "application service provider" (ASP) distribution model according to which the service provider distributes the software as a service over the Internet to every business sector while maintaining installation by segment (silo deployment) on his infrastructure[5]. It was originally thought that the cost components such as equipment costs, operating costs, human resources of procurement and maintenance, non-availability service costs etc. (CaOpEx) which burden the business sector will be reduced dramatically. This model, however, merely reduces some costs while the CaOpEx cost parameter shifts from the sector to the provider. As a result many implementations of the ASP failed and the model waned over time. The distribution model "application service provider" (ASP) is shown in the graph below.

With the presence of Cloud Computing and technologies that support its use, the "on-demand software" or "Software as a Service" (SaaS) software distribution model appeared according to which the software is installed and operated centrally by the service provider and allocated to the business domains via the Cloud in the form of software services. The software manufacturer (ISV) can perform the role of the service provider or may cooperate with a third service provider (Internet service provider, communication service provider, data center operator etc. who and/ or hosts the software and/ or provides distribution channels for the service. The fundamental SaaS model differentiation is that the business sector makes use of the software while the service provider undertakes infrastructure resources, operation and support.

An immediate perceived advantage of the SaaS model for the business domain is the dramatic reduction of the CaOpEx cost parameter and the direct RoI (Return of Investment) which translates to orders of magnitude of cost reduction compared to the "on-premises" model and the ASP model. The above advantage applies where it does not translate into a disadvantage for the service provider and the software manufacturer. Specifically, the advantage is valid based on the following conditions:

• The displaced cost component towards the service provider ensures large scale cutbacks and is not cumulative for every business sector installation
• The additional costs resulting from the transformation of software into services such as software development or modification, promotion, on-line training and support, etc., add up in the total software service providing cost per business domain
• The total cost of providing software services per business domain is significantly lower than the total cost of "on-premises software" per business domain
• The distribution cost per software service and per business domain is such as to achieve distribution to many business domains with a relatively low cost per domain (long tail retailing strategy)

Ensuring the above conditions is fundamental to the overall success of the SaaS model and concerns as much the service provider as the software vendor. Otherwise the investment doesn’t retain elements of sustainability.

The recognized need

Even if SaaS is present as a model, as a proposed architecture and with actual deployments, there is not a specific implemented technology platform capable to consume effectively the SaaS architectural principles and provide a complete platform for the SaaS delivery model. This technology platform should isolate the SaaS functionalities from the provided software service and from underlying infrastructure. In other words the requirements imposed by the SaaS model should be captured and be implemented in a technology platform capable to interface with software applications and Cloud infrastructure and provide self-sufficiently SaaS required functionality.

On the other hand, capturing the imposed requests from the major stakeholders of the model and addressing the expected benefits, as it is shown in the diagram above, and by analyzing the function of the SaaS delivery model, the aforementioned requirements and constraints could be organized in three major categories or axes:

• SaaS-ready™: includes all software architectural transformations required to be applied on a software application in order to serve multiple tenants through a single deployed instance. These software transformations fulfill requirements imposed by multitenancy, software oriented and tenant-centric architectural principles of SaaS.
• SaaS-enabled™: includes all business support functionality required to be applied on a software application in order to enable it as a retail product towards tenants. This business support functionality involves services such as tenant management & activation, software service request management, software service catalog and software usage rating& billing.
• SaaS-enabled™: includes all operational support functionality required to be applied on a software application in order to manage it and operate it as a software service. This operational support functionality contains services such as software service fulfillment and provisioning, software service delivery, software service assurance and software inventory & management.

The above classification of SaaS model constraints demonstrates that SaaS-ready™ axe affects vertically the architecture of the software application while SaaS-enabled™ and SaaS-managed™ axes support horizontally the software application operation. Under this scope the problem could be rephrased as follows:

Is there any technology platform which works as a grid among software transformations and support services capable to provide SaaS-ready™, SaaS-enabled™ and SaaS-managed™ functionalities in order to offer SaaS in-a-box?

The only way to provide the aforementioned functionalities in order to offer SaaS in-a-box is through our innovative technology platform called: SaaS.fabric™

In a single tenancy environment, a single instance of the software and supporting infrastructure serve a single customer. So each customer has his or her own independent database and instance of the software with no sharing. Although supporters talk about security issues, dependability and customization, high costs relating to maintenance, setup/management and inefficient use of resources (since there is only one customer for the entire environment) have shifted preference and increased demand for multitenancy SaaS applications.

In a multitenancy environment a single instance of the software and its supporting infrastructure serves multiple customers. Each customer shares the software application and also shares a single database. Each tenant's data is isolated and remains invisible to other tenants.

There main advantage of multitenancy in cloud computing is economies of scale mainly in terms of:

• Better use of resources: One machine reserved for one tenant isn't efficient, as that one tenant is not likely to use all of the machine's computing power. By sharing machines among multiple tenants, use of available resources is maximized
• Lower costs: Economies of scale: companies of all sizes can share infrastructure and s/w costs

Multitenancy simplifies:

• Updates/Changes: can be applied uniformly, leading to huge time savings
• Maintenance: significant part of database maintenance is handled by the automation provided by the vendor so that customers don’t need to pay maintenance fees to keep up to date
• Configuration can be done while leaving the underlying codebase unchanged

If you want to see how multitenancy architecture can efficiently support your SaaS projects visit petranna.db