SaaS - A Software Application Delivery Model

In traditional software development, companies were required to buy, build, and maintain their own IT infrastructure despite exponential costs. Even an SME needed an IT manager who was responsible for managing all type of IT-related work - installing applications, maintaining software and systems, backup management, patch management, disaster and recovery management, security systems, licensing issues, hardware procurement and upgrades. All this resulted in significant overhead for organizations of all sizes and needed a dedicated team.

Traditional software distribution, in which software is purchased and installed on PCs, is sometimes referred to as software-as-a-product (SaaP).

Today in a world of specialization, organizations just want to focus on their core business and outsource other work to specialist organizations better equipped for handle it and at cheaper prices. Nowadays companies want their business portals to be managed by specialized third-party IT firms that take complete ownership and responsibility for managing the show.

Software-as-a-service (SaaS) redefines the software deployment model of packaged applications with its upfront licensing fees and lengthy implementations into a subscription-based Internet-delivered service relationship.

This article explains SaaS, its characteristics and benefits, and touches on designing and architecting SaaS applications.

Before we start discussing SaaS let's recap the software's evolution. Figure 1 doesn't capture all of software's evolution here, but definitely hit its major milestones.

What Is SaaS?
"SOFTWARE DEPLOYED AS A HOSTED SERVICE AND ACCESSED OVER THE INTERNET."
SaaS is defined as software-as-a-service and provides access to software and its functions remotely as a Web-based service over the Internet. It supports Service Oriented Architecture (SOA) and Web 2.0 standards like Web Services and AJAX, and a SaaS provider maintains and manages the applications.

An SaaS application is offered either directly by the vendor or by third-party SaaS providers responsible for the application's availability (maintenance, scalability, disaster recovery) from their locations and it is good for the SME under constant pressure to reduce IT operational costs. The SaaS model can help save time and money by shifting responsibility for software delivery to a service provider.

The SaaS model is found mainly in line-of-business services like CRM, e-commerce, and finance to facilitate the business processes of enterprises and organizations of all sizes and is also applicable to consumer-oriented services.

SaaS Characteristics
The SaaS sector is one of the fastest-growing segments in software. IDC believes that telecom companies like AT&T and Softbank and professional service providers will act as viable sales channels.

Some of the characteristics of SaaS mentioned by IDC are:

• Network-based access to and management of commercially available software (i.e., not custom)
• Activities managed from central locations rather than at each customer's site, enabling customers to access applications remotely via the Web
• Application delivery typically closer to a one-to-many model (single instance, multi-tenant architecture) than a one-to-one model, including architecture, pricing, partnering, and management characteristics

Multi-tenancy means hosting multiple customers on a single server, which is how on-demand service applications are provided. The code for the software runs on a remote machine, and a single instance of it is accessed by 'n' number pf end users of multiple customers. In SaaS-speak the word tenant refers to the customers for whom installation and configuration is done. In the SaaS model we have four main stakeholders: (See Figure 2)

1. SaaS End Users - The application users or, say, Internet shoppers in the case of an e-commerce application
2. SaaS Customers - Enterprises that buy the services and use it
3. SaaS Aggregators/ISVs - Software vendors or intermediate parties that bundle the different SaaS applications.
4. SaaS Hosters - They host the SaaS applications on their Web/application farms.

It's quite possible that in some cases only one party plays the roles of ISV, SaaS aggregator, and SaaS hosters or it's possible that the aggregator/hoster is one party and the ISV is different.

Types of SaaS Provider
If we talk to 10 different experts about what SaaS is and how it's related to ASP and on-demand, we are bound to get 10 different answers. Some will say SaaS, ASP, and on-demand applications are variants of hosted or managed services and some would say SaaS is more generic compared to ASP and some might say SaaS is the same as ASP. But it would make more sense to say SaaS providers are classed into two categories:

1.  Hosted AM - The hosted application management (hosted AM) model is similar to traditional ASP. In this model a customer buys software and asks a hosting company to host it for him or a provider hosts commercially available software for customers and delivers it over the Internet. In this model applications typically support a single-tenant architecture and their ability to share data and processes with other applications is limited. HAM is based on a one-time licensing in which the software manufacturer is paid license fees and the hosting company hosting fees.

2.  On-Demand - In this model the provider offers customer an application that support multi-tenant architecture, i.e., software built for one-to-many hosting in which one copy of software is installed for the use of many companies and accessed over the Internet. On-demand is a subscription-based model where the client pays subscription fees (per user, per transactions, number of hits, per project, monthly, yearly, usage, transactions) to the provider for using the application.

Note: There is one more model referred to as an appliance model. Here the vendor supplies a hardware/software component as a "black box" that is installed at the customer's/end user's location, instead of being at the vendor's like the PDAs with special software used in life sciences or shipping, and special devices are provided for application to end users.

Architecting SaaS Applications
Designing any kind of project is never easy and defining an architecture for SaaS applications is even more difficult. Architects have to make a major shift in their thinking before starting to design SaaS applications.

For designing an SaaS application architecture, architects have to design software that meets each customer's business needs as well as the SaaS model requirements. SaaS applications are a bit different from traditional applications as to:(See Figure 3)

1.  Location: SaaS applications are hosted at an SaaS provider's location whereas in the SaaP model the software is installed in the customer's IT environment.
2.  Licensing: An SaaS application is based on a subscription or metered model (use-based, say, the number of transactions), whereas in SaaP it's a one-time license model.
3.  Management: SaaS providers manage all the tasks and activities not transparent to customer and service level agreements (SLAs) govern the quality, availability, and support commitments that the provider makes to the subscriber, while in SaaP organizations the customer's own IT department is responsible for managing all tasks.

So "pure SaaS" applications religiously follow and comply with the three aspects above. In traditional software development as a product we target one customer for each license and these customers can have 'n' number of users.(See Figure 4)

While defining the architecture of SaaS application we always have to consider the requirement of all the stakeholders and each of these stakeholders has his own unique architectural requirements. For instance:

1.  Delivery architecture requirements - SaaS hosters looking for an architecture that meets their delivery requirement, i.e., a secured multi-tenant architecture where one common code/single installation will be able to handle more than one customer.

2.  Application architecture requirements - SaaS aggregators and ISV are looking for applications that are scalable, configurable, extensible, open-ended, loosely coupled, secure and support multiple environments.

3.  Consumption architecture requirements - SaaS customers (like, say, SMEs) are looking for architectures where they can save money, upgrade easily to new systems, integrate with new systems, customize business rules and the UI as they need using applications that can be accessed globally.

4.  Usability architecture requirements - SaaS end users are looking for a fast response time, ease of use, personalized information, etc.

An SaaS application's maturity can be expressed using a model at four distinct levels(See Figure 5)

A.  Level 1 (ASP model) - Ad hoc: At this level each customer/tenant has its own customized version of an application up and running on host servers. Most of current Web applications are at this level and if they're not then they can be ported with little or no effort.

B.  Level 2 - Configurable: At this level, each customer/tenant's separate instance of an application is hosted. That means the same code implementation is used for all customers. Applications provide many configuration settings so the applications' UI and behavior can be customized according to a customer's requirements without making changes in the code.

C.  Level 3 - Configurable and Multi-tenant: At this level, all customers share the same instance of an application and with the help of configuration settings the application's behavior and UI changes for every customer at runtime. It's important that security be well defined and implemented to keep each customer's data separate.

D.  Level 4 (Pure SaaS) - Configurable, Scalable and Multi-tenant: At this level multiple instances of the same application are up and running. Load balancing infrastructure decides at runtime which instance is used by which customer. Here one customer can be served from more than one instances of the application or one instance can serve many customers.

SaaS customers want to customize the application services they subscribe to and the challenge is we have to build an SaaS application to meet their expectations. We have to ensure that the task of customizing applications is simple and easy for the customers, yet at the same time not incur extra manual development or operation costs for each customization.

In addition to domain features a pure SaaS application should also support the

1. Ability to create custom business workflows and customize the existing ones.
2. Ability to define new business documents and customize existing ones
3. Ability to define new custom business entities and rules and customize existing ones - the idea is that we should either use rules engines or a mechanism to define the rules outside the code file like in database or XML files so they're not hard-coded and can be easily modified if required.
4. Ability to define custom validation rules and customize existing ones - the idea is that the application should have some validation frameworks so every customer can build custom validation rules to fit his requirements with ease apart from OOTB standard validation rules.
5. Ability to define custom reports and customize existing ones - every customer has his own requirements for reports for analysis besides standard domain-specific reports. So the application should provide this facility; it could be provided either by building some in-house reporting feature or integrating with DW or reporting tools like Cognos/Crystal Reports.
6. Ability to add new features and customize existing ones with minimal manual effort.
7. Ability to customize the UI, i.e., customizing brands, logos, look and feel and navigational flows.
8. Ability to integrate and exchange data with external systems easily.
9. Ability to support disparate clients (Web, wap, imode).
10. Support SEO features (like Search Engine Friendly metatags, etc).

So are we asking too much, the best of everything in world?

The answer is yes, it's true and this is the only way we can really come up with a pure SaaS application. Now imagine that we have to develop software that can handle 'n' number of customers and each customer has 'n' number of end users and complies with all the requirements mentioned. Some of the things that have to be done at each layer of architecture so we can achieve the desired results are:

1. UI Layer: The UI layer should be highly customizable in terms of look and feel and should support I18N. If the application supports this then the application's UI can be easily configured or customized according to customer requirements. This can be achieved by following some of the approaches below:

   a)  Rendering the entire UI using CSS/XSL and allowing customers to define their own CSS/XSL.
   b)  Providing the ability for customers to do extensions or add their own scripting files/methods. c)  Providing flexibility so the UI can be changed or display additional information like promotions based on external factors such as information provided through URL parameters.
   d)  Loosely coupling the data rendering logic from the business processing logic so the customer or provider can change the placement of the forms/data rendered on UI. Easypage is a good example.
   e)  Using an XSLT approach can add further value in providing disparate client support.
   f)  Furthermore it would be good if the application provides the flexibility to map the UI by locales, branding, etc.
   g)  Personalization support (both implicit and explicit).
   h)  Search Engine Optimization should be supported if possible.
   i)  Provide a rich UI.

2. Integration Layer: The integration layer in SaaS should be such that it allows a system to integrate with third-party systems easily in a standardized way. This can be achieved by:

   a)  Following an interface-based API, JCA approach.
   b)  Allowing support for a messaging system and Web Services.
   c)  Using business orchestration tools and standard integration tools like SeeBeyond and webMethods.

   For data exchange it's always advisable to follow standard formats like industry standard XML structures or EDI instead of proprietary ones.

3. Data Access Layer: A pure SaaS application is designed in such a way that it is easy to support different data sources, for example, databases or files or third-party systems based on requirements. Keeping this in mind:

   a)  It's advisable to use OR mapping techniques like Hibernate and JDO.
   b)  Create middleware components that allow us to make system data source-independent system.

   As we know the database is the most important part of any application and we should spend a good amount of time defining and analyzing the database architecture. To manage multi-tenant data we have three approaches:(See Figure 6)

   c)  Isolated Database for each customer - This way we create a new database for each customer; it is the easiest, most secure, and costliest approach. In this case maintenance overhead (for example, backup and recovery) is low, reliable, and easy to enhance the database to customer-specific requirements.

   d)  Shared Database and Isolated Schemas - In this approach multiple tenants share the same database, but each customer would have a separate schema. This approach is also easy and provides a facility to make customer-specific changes in the database but it is less secure and not very reliable compared with the isolated database .In this approach maintenance overhead (again backup and recovery, for instance) is high.

   e)  Shared Database and Shared Schemas - This is the cheapest solution in terms of deployment and maintenance. All the customers share the same database and schema, maintaining data for all the tenants in the same set of tables. We have to put extra development effort in to make it secure so that data isn't shared by tenants by mistake.

The cost (application, deployment, maintenance), volume of data, number of customers, and security level are some of the deciding factors that help us in identifying the right approach for designing the database for our SaaS application.

An SaaS application database should support I18N and design should be extensible enough to provide enhancements easily or change the database to meet customer requirements. Based on the clarity of the requirements, an understanding of the domain requirements now and in the future can achieved by providing additional non-mandatory columns of a generic type in the tables or following a name-value pair approach to define the database structure. Security plays a key part in an SaaS application and one must provide an adequate security mechanism to avoid any unauthorized access to customer data. SaaS applications should provide support for standard SSO and security techniques (like digital signatures, ACL, message encryption, etc.).

On the technology front an SaaS application should be loosely coupled, highly cohesive, and designed to avoid use of proprietary databases and middleware. It should use open source and follow industry standards like XHTML, 508 compliance, XML, AJAX, RSS/ATOM, etc. When defining an SaaS application we should keep Web Services in mind and, if possible, follow a SOA architecture.

The key to developing a good SaaS-based application is the design of the application framework. We have to make sure that the base application framework should be flexible, open-ended, and robust enough so new features can be added to an application easily. This way we can create a customer community that will contribute developed features to our SaaS applications. This has two major benefits:

1. Our SaaS application becomes feature-rich and these new features can be offered to other customers based on a license or terms & conditions of the customers who had it developed.
2. It attracts more new customer to use our application that results in improved revenue figures.

Table 1 summarizes the technical application requirements and suggested approaches.

I. Benefits of SaaS
A)  Benefits for SaaS customers.

1. Freedom to focus on core business - Customers can now focus and channel their energy on their core business and there's no need for them to spend money, time, or effort in concentrating on internal IT departments.

2. Save Cost & Time
   a. Lower IT costs - When customer we go for SaaS, they spend money in their own IT department
   b. Low pricing and better budget forecasting - SaaS pricing is based on a monthly fee that's actually cheaper than paying for licensed applications. It also helps organization forecast IT expenses.
   c. Save time in development, deployment, and maintenance -SaaS applications are ready to go and maintained by the SaaS provider so the customer is free of these responsibilities.

3. No extra hardware required - Software is hosted remotely so the customer doesn't need to invest in additional hardware except for the PC needed to access the application.

4. Less software required - Customers may only need a browser to use the application or maybe a plug-in for some software.

5. No installation needed, easy maintenance, scalability, and availability - SaaS providers do the installation, setup and often the daily upkeep, 24/7 uptime, application security, monitoring, and maintenance.

6. Availability of new industry standards and technology trends. -SaaS providers constantly update their application to incorporate new technologies and standards related to both IT and business to remain competitive. SaaS customers benefit from this.

7. Service level management - A simple SLA covers the responsibility of the SaaS providers and SaaS customer. This should be well defined for areas like performance and availability, security, DR&BP, and licensing.

8. Greater satisfaction and freedom of choice - SaaS vendors should see a higher level of customer satisfaction, broader user adoption and higher renewal rates. And if SaaS customers are dissatisfied, they can move to a different SaaS provider.

9. Global accessibility - Customers can extend their services to new geographic locations.

B) Benefits for the SaaS provider or aggregator

1. Low Cost and Time:
   a. Setting up a portal for a new customer is easy since all customer share the same implementation.
   b. Cost is saved for the same reason.

2. New customers - With reduced overall costs and more value-added services, more SME will start availing themselves of the benefits of Web applications.

3. Easier administration - Because of shared resources, administration is easy. Fewer people are needed.

4. Easy configuration management - With most customers using the same code base the provider has less overhead maintaining the CM for each of them.

5. Automatic updates and patch management - Upgrades are automatically pushed to end users, reducing effort and allowing vendors to deliver more targeted customer support.

6. Easier collaboration and version compatibility - All customers have the same software version so upgrades and maintenance are simplified.

7. Easy to rollover new standards and technology - Since all customer share the same instance/code implementation it's easy to add new features or introduce new standards or technology innovations to all or most customer in a few shots

FAQ
Q1. Does On-Demand and Application Service Provider mean the same thing as SAAS ?

A. SaaS can be seen as an improved version of the older application service provider (ASP) technology while on-demand is an expression used by many companies to describe a set of products and services. SaaS is a key tool in achieving on-demand capabilities.

Q2. Are there any companies that support SaaS?

A. Yes. There are lots of companies that either provide platforms or standards or create SaaS-based products A few of them are: Microsoft, SAS Institute, Salesforce.com, NetSuite, Symantec, BMC Software, Macrovision, ATG's OnDemand Solution, SugarCRM, Intacct, Buizmatics, and Ibackup's Profit Cents.

Q3. Is any threat to data security from SaaS applications?

A. No. Well-architected, well-made SaaS applications don't have this problem, but it also depends on how the SaaS provider implemented the security model and what the security and backup policies are.

Q4. Can each SaaS customer have a separate database?

A. Yes. There are three approaches in which an SaaS application can manage multi-tenant data, Please read the Data Access Layer part in this article.

Q5. Is SaaS a viable option for all Web-based applications?

A. No. There a few cases where SaaS is not a good option, For example, if the applications requires:
a. Integration with other systems
   I. When it requires tight and ongoing integration with legacy and in-house systems.
   II. When it requires integration with applications supported by other SaaS vendors especially if their systems aren't interoperable.
   b. Implementation of SaaS customer-specific business processes and workflows
   I. When the situation requires implementing unique business processes specific to a customer for competitive advantage or code-level modification.

Q6. Is a SOA architecture necessary to make a Web application a SaaS application?

A. No. but SOA architecture plays a key role in making a better SaaS application.

Q7. Is SaaS technology-specific?

A. No. Any application accessed over the Internet regardless of its technology can be an SaaS application.

Summary
SaaS has become one of the fastest growing segments of the IT sector because it provides organizations with turnkey software solutions that can be implemented quickly avoiding incremental infrastructure costs and eliminating the ongoing administrative resources of traditional on-premise applications. Table 2 compares SaaS- and non-SaaS-based applications.

An SaaS application is accessed over the Internet and is distinguished by three qualities, scalability, configurability, and multi-tenancy, and its architecture is open-ended, highly scalable and extensible, loosely coupled, easily configurable, fully secure, and highly customizable. Supporting Web services and SOA, it's easy to add new Business Services in an application and enable an SaaS application to integrate with other SaaS applications. The key to developing SaaS-based applications is the design of the applications framework. Application frameworks should be flexible, open, and robust enough for new features to be added easily to an application.

So adopting a SaaS model is a win-win situation for both the SaaS customer and the provider/aggregator. It's also beneficial to all SME who can't afford to have dedicated or in-house business applications, but need a Web presence to stay in business and be competitive.

References

1. Software as a service: http://en.wikipedia.org/wiki/Software_as_a_Service
2. Architecture Strategies for Catching the Long Tail: http://msdn2.microsoft.com/en-us/library/aa479069.aspx
3. Multi-Tenant Data Architecture: http://msdn2.microsoft.com/en-us/library/aa479086.aspx
4. Software as a Service (SaaS): An Enterprise Perspective: http://msdn2.microsoft.com/en-us/architecture/aa905332.aspx
5. Perspectives of the IASA - Special Issue: Software as a Service: http://files.skyscrapr.net/users/fredch/blog/iasanewsletterdec2006.pdf
6. White Paper: Five Benefits of Software as a Service: www.trumba.com/connect/knowledgecenter/software_as_a_service.aspx
7. IDC predicts SaaS trends: www.networkworld.com/weblogs/applications/011589.html
8. Trends in Software as a Service: www.pcworld.com/article/id,135119-pg,1/article.html
9. Software On Demand: www.forbes.com/enterprisetech/2004/07/20/cx_ld_0720bizondemand.html

Credits: The author wishes to thank his colleagues Saurabh Bhatnagar and Vikas Wadehra for their valuable contributions in reviewing this article.