SaaS-Value Proposition

rahulgangwar — Wed, 25 Jul 2007 01:13:00 GMT

Is the Total Cost of Ownership of a SaaS application really low than a traditional application for an end user?

SaaS is buzzword in today’s delivery model of software. Many ISVs are hastily looking for converting their existing traditional applications on to the SaaS strategy. Once the product finally moves onto SaaS delivery model, then starts the process of attracting customers/end-users. The primary reason that customers (especially SMBs) are told to move to the SaaS product is that the total cost of ownership is low for them. The tenants don’t have to invest on the hardware, maintenance, employing IT staff etc. Moreover, customers are charged on per month/pay as use etc. model. SaaS offers so much of flexibility in terms of acquiring the software that customers fall prey of SaaS product immediately. The value proposition of TCO is so much tempting. That’s a good thing but at the same time this value proposition is basically confusing the customers about the other value propositions about SaaS. Not only this, at few instance the value proposition of TCO is actually wrong. There has to be a good understanding among both ISVs as well as customers about the concept and philosophy of SaaS in order to fully appreciate the SaaS model.

Let’s talk about the TCO of a SaaS application for a tenant. When a tenant buys a SaaS application, definitely, the TCO is low as compared to its traditional approach version. But how far? If we take an example where the customer is going to use the software for typically longer period it is quite possible (not necessary) that SaaS application will cost the customer much more than the traditional version. It will actually be cheaper for the end user to buy the software, build infrastructure and maintain it rather than paying on a monthly basis. Yes that is true.

I can give an analogy to the real world to understand the concept. When I go out to another city (maybe for vacation) I will need a vehicle to move around the city. I have two options there, buy a new car for me or hire a cab. Of course since I am there for a less period, the cab will intuitively be a better option. But what if I use cab even in the city where I live? Definitely as time moves from one year to another and so on, I will realize that buying a Car was a better option. Similar is the concept of SaaS application. In software field, some things change and are not same as the real world of Cabs and Cars. Those differences are the real value proposition for SaaS according to me.

For example, in software world, our needs/business requirements changes and we will need a framework to accommodate these changes into our existing infrastructure without investing heavily. Of course, it will not be a good idea to get a new version of application according to our business changes. SaaS application is built from ground up keeping these business changes in mind. A SaaS application provides the flexibility to customers to change the business rules.

Among other features that make SaaS approach more valuable include ease of sharing Data to third parties, availability of backup data centers for disaster recovery and, especially for smaller businesses, having access to the enterprise level application services that would be near impossible to achieve in-house.

Among other benefits of moving to SaaS, if I start counting I see the list endless. Things like achieving on-demand scalability just by a little extra, turning variable cost into fixed costs by delegating the variable costs on to the hosting provider, Integration with other LOB applications… list is endless.

The idea that I want to convey here is that for end users cost is not the sole value proposition, but when we look at the total value that SaaS can deliver, SaaS becomes even more compelling.

Rahul

How to SaaS

rahulgangwar — Tue, 27 Mar 2007 22:20:00 GMT

This is my first blog entry and I am happy to get this blog meant only for Microsoft Full Time Employees.

Okay coming on to the title for this blog post. Today I am going to write down on Sofware as a Service (SaaS) architecture strategy.

I will un-cover the technical aspects involved in building a SaaS application and very high level overview of the technical aspects of a SaaS solution.

These concepts can be applied to any Application which is a good candidate for a SaaS application.

Contents:

1. SaaS- Introduction

2. SaaS -Challenges

3. SaaS -Solution to challenges

SaaS-Introduction

A SaaS application can be defines as any “Software deployed as a service and accessed using internet technologies”. In order to realize a SaaS solution (in fact any solution) we need to do two things:

1. Build our application which can be used as a service over internet by different clients. This could range from a programmatic service (accessed programmatically by other softwares) to a stand-alone application used by different clients. This step is involves us to follow certain steps that are different than developing a normal “On-Premise” or simply called a non-SaaS application.

Typically when we develop an application (a non-SaaS application) then we do assume two things:

· Application will be installed at client side (e.g., a desktop application) be it through a CD or downloading via internet. This also implies that the client will have to do the maintenance (like upgrading to new version, apply patches, maintain databases etc.) of application even after he has bought the application (not true for Application Service Provider model). This fact is not true in terms of a web application. So we can say that any web application forms a different category of application since it is not installed at client side. But still we cannot call ANY web application a SaaS application.

· Application will be served to requirement of a particular client. If another client needs some changes in the application, we will make changes in the application source code and then run another instance of that application for the new client. So in nutshell, we assume that one application is meant for one client only. This assumption is true even for a web application.

Here comes the difference! The core of a SaaS application is based on the opposites of these two (above mentioned) assumptions. The following are assumptions that are true for a SaaS application.

· Application will be typically deployed and maintained by a hosting provider. So, clients don’t have to invest in terms of buying hardware resources and employing the IT staff to manage the application. This will be done by the hosting provider.

· Application will be accessed by clients using internet. In special cases where a SaaS application is hosted inside the enterprise itself this is not true but still the clients accessing the hosted application will still use internet technologies to access the application.

· A single SaaS application (in fact a single database too) serves more than one client having different needs. So the application will be designed in such a way that only a single application instance will be able to provide different functionalities to different clients. This model is more popularly known as Multi-tenant model.

Among these assumptions, the last assumption related to multi-tenancy requires a SaaS application to be architected in a special way keeping in mind about certain aspects of a multi-tenant application. These aspects form the challenges of building a SaaS application and also our next topic of discussion.

2. SaaS world does not end just by building the application that satisfies SaaS characteristics. Deploying a SaaS application forms another set of challenges. Typically a SaaS application is deployed by a SaaS hosting provider and the hosting provider is responsible of maintaining the application. So, not only clients get rid of maintaining the application but also ISVs get rid of that aspect.

Microsoft provides end to end resources in developing and deploying a SaaS application. It provides resources ranging from development frameworks and technical resources used to build and design the application to hosting options that assist in deploying the application.

SaaS-Challenges

As we have seen that one of the important characteristics of a SaaS application is multi-tenancy, this aspect implies further challenges in building a SaaS application. Let’s see those challenges after trying to define the multi tenancy.

Multi Tenant Architecture:

A single SaaS application serves more than one client having different needs. This means that you run only one instance of the application and that single instance will be accessed by all clients. For example, you built a CRM SaaS application and hosted it over a SaaS hosting provider. Now many organizations have different CRM needs depending on the nature of business they do. We will not build any separate application for all the companies but our single application will have the option using which each client will customize the SaaS application according to his need. Not only that a single database can be used (not always) for storing data of different clients. So security is also a major concern. Let’s see all the concerns and challenges that we need to consider while building a SaaS application.

Challenges

Here are some important challenges that we need to consider while building a SaaS application. It is important to note that not all challenges are required in a single SaaS application. These challenges depend on your application’s requirement. Here only the challenges are presented. Next section will deal about ways to address those challenges.

Business Agility:

Different organizations can have (in fact they do have) different business needs. For example process of approving a loan in two banks may be different in a way that Bank-X requires a Loan Manager to approve the loan request document before sanctioning the loan while Bank-Y requires both the Loan Manager and Bank Manager to approve the loan request. Now if we are building a SaaS application to target these different business requirements, then, we must provide a way through which different clients can configure the SaaS application according to their business requirement. This is what we mean by Business Agility (we can call it as ability of an application to configure its business rules).

User Interface Configurability:

Each client of our SaaS application might have the requirement to change the UI of the application according to their need. This could range from configuring color, font, Company Logo etc. to positioning , ordering of UI elements (for example web parts) etc. incorporating this capability of configuring the UI of a SaaS application according to client’s requirements form another requirement and thus challenge to building a SaaS application.

Database configurability:

Since typically a SaaS application uses a single database (not always) for every client, all the data of different clients can be stored in a single database. This approach makes a SaaS application more efficient since only a single database is used but this also poses challenges on how to design the database so that different data model needs can be accommodated in a single database approach. This approach is commonly known as Multi-tenant database.

Security:

Since a single application instance caters to requests of all clients, it is important (in fact a must) that we have some mechanism to make sure that data of each client remains secured and users of a particular client can access data meant for them alone.

Scalability:

A single application can be used by different clients and each client can have a number of users accessing the SaaS application. This puts a constraint that the application must be able to handle increased number of users. Scalability is a challenge that has to be handles at 3 different levels: The SaaS application (your code) must take care of scalability issues, the SaaS application server (generally done by hosting providers) must be scalable and then finally the database server must be scalable. Scalability at all these three different levels is achieved using different techniques that we will see later on.

SaaS-Solution to Challenges

We will take all the challenges, discussed in previous section, one at a time and propose techniques used to address these challenges. To some techniques we will provide the direct links to already existing resources instead of dwelling those techniques in detail out here.

Business Agility:

This aspect involves designing your SaaS application architecture in such a way that clients of the application can modify the business logic written in your application. Now, how do we provide the modification of business logic of application without writing new code or even modifying existing code?

The most commonly used approach is Metadata driven architecture. Let’s see how it work and what ways (maybe tools etc.) do Microsoft helps in designing such applications.

Concept of metadata driven architecture is quite simple and complex aspects are handled by Microsoft technologies and tools. In a metadata driven system there are three major steps involved:

Metadata: Whatever features of an application are to be configured during runtime, we define those features of the application in the form of Metadata (it could be an XML file stored on hard drive or a backend database). This metadata can be extended by writing more data to it.
Metadata Services: A set of programmatically accessible services are designed that provides an interface to access/modify the metadata. This can be thought of as an interface layer or façade layer. We provide these services so that metadata can be exposed (maybe over internet) to any application/tool while keeping the integrity, validity etc. of the metadata intact. Imagine a situation where an application (by mistake) modified the metadata that violates some core semantics of metadata. Providing an interface layer to any data store is a common principle in building a distributed application and any SaaS application is on first place a distributed application.
An Engine: The business layer of our SaaS application will be nothing more than an engine that runs the business processes defined in the metadata store and accessed using metadata services. These steps could be a bit complex depending on the configurability requirement of your SaaS application therefore Microsoft provides a number of options to build such systems.

Most commonly used technology is using BizTalk Server. BizTalk server has two main components:

A process execution engine that manages the steps, applies the business logic, and invokes the supporting applications of a complex process and/or transaction set.
A multi-transport messaging hub for transforming and routing information to and from applications and process steps.

Another technology seen by developers in their most loved development environment (Visual Studio) is Windows Workflow Foundation (Part of .NET Framework 3.0) used to model business processes as workflows.

Yet another technology from Microsoft is Microsoft Web Services used to build Service oriented applications which in turn is essential to deliver the business agility and IT .

For more details on these technologies you can refer to following resources:

http://www.dmreview.com/article_sub.cfm?articleId=1075079

http://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/business-rules-framework-overview.mspx

http://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/bpm-solution-overview.mspx

http://msdn2.microsoft.com/en-us/architecture/aa699456.aspx

http://msdn2.microsoft.com/en-us/architecture/aa948857.aspx

User Interface Configurability:

The process involved in allowing end users to modify the user interface according to their need is similar to achieving Business Agility- Using Metadata Driven Architecture. End-user preferences are stored in form of Metadata and UI is composed using this metadata. User interface metadata defines connections into user interface elements, such as menus, Windows Forms controls, and HTML.

http://msdn2.microsoft.com/en-us/library/ms954610.aspx

http://www.microsoft.com/technet/solutionaccelerators/cits/iwp/ibf/soldev/moibf1_sdg_07.mspx

http://msdn2.microsoft.com/en-us/library/aa480019.aspx#aj1metadat_topic13

http://msdn2.microsoft.com/en-us/library/ms136029.aspx

Database Configurability:

For a SaaS application we can use different databases for each client and also use single database for every client depending on the need of the application. This asks us to design a Multi-Tenant Data Architecture (where tenant is equivalent to client).

This involves choosing an approach to in a given scenario and also how to realize that approach. There is a very good article dedicated to developing a Multi-Tenant database system. I would recommend going through that article while going to develop the data model for your application.

http://msdn2.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Arcast:

http://www.skyscrapr.net/blogs/arcasts/archive/2006/07/18/232.aspx

Security: (Most of the content of this heading is from the famous Catching the Long Tail article)

As we discussed earlier, security is an important aspect of a SaaS application (in fact any application). Security requires special attention for a SaaS application because a single application instance is serving different clients. This poses two major challenges:

How will the administrative tasks related to security handles? For example, creating new users, security policies, and permissions etc. for every client is obviously different.
How to keep client specific request secured? This also involves keeping data for clients secured even if we have data for different clients in same table.

There are different techniques and patterns such as filtering, encryption etc. Let’s see an overview of how are security requirements handles by a SaaS application.

Common approach is to create security services for the application. So security is also applied in the form of services (sole reason is to incorporate the distinct requirement of SaaS application). SaaS application is built on the foundations of SOA (service oriented architecture) and services are building blocks of any SOA application. Typically we divide security services into two components:

Authentication Services
Authorization Services

The SaaS provider typically delegates to each tenant the responsibility for creating and maintaining its own user accounts, a process known as delegated administration. Delegated administration creates a situation in which the customer is responsible for creating individual user accounts, but the vendor has to authenticate them. To accommodate this delegated-administration model, SaaS designers use two general approaches for handling authentication: a centralized authentication system, or a decentralized authentication system. The approach that you choose will have ramifications for the complexity of your architecture and the way end users experience the application, and you should consider what your business model says about the needs of the application, customers, and end users when making a decision.

In a centralized authentication system, the provider manages a central user account database that serves all of the application's tenants. Each tenant's administrator is granted permission to create, manage, and delete user accounts for that tenant in the user account directory. A user signing on to the application provides his or her credentials to the application, which authenticates the credentials against the central directory and grants the user access if the credentials are valid.

This approach requires a relatively simple authentication infrastructure that is comparatively easy to design and implement, and that does not require any changes to the tenant's own user infrastructure. An important disadvantage to this approach is that a centralized authentication system makes it much more difficult to implement single sign-on, in which the application accepts the credentials that the user has already entered to gain access to his or her corporate network. Without single sign-on, users are frequently presented with an inconvenient login prompt when logging in to the application, and they must enter their credentials manually.

In a decentralized authentication system, the tenant deploys a federation service that interfaces with the tenant's own user directory service. When an end user attempts to access the application, the federation service authenticates the user locally and issues a security token, which the SaaS provider's authentication system accepts and allows the user to access the application

This is an ideal approach when single sign-on is important, because authentication is handled behind the scenes, and it doesn't require the user to remember and enter a special set of credentials. The decentralized approach is more complex than the centralized approach, however, and a SaaS application with thousands of customers will require individual trust relationships with each of the thousands of tenant federation services.

In many cases, the SaaS provider may want to consider a hybrid approach—using the centralized approach to authenticate and manage users of smaller tenants, and the federated approach for larger enterprises that demand, and will pay for, the single sign-on experience.

To understand more about security concepts and how to apply them you can refer following resources:

http://download.microsoft.com/download/5/c/4/5c49d9c8-a3e9-4806-8c6d-a621b8d2402b/Windows-basedHosting_CentralizedManagement.doc

http://www.microsoft.com/technet/security/guidance/identitymanagement/idmanage/P1Fund_4.mspx?mfr=true

To configure security at database level use guidelines given in following resource:

http://msdn2.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Scalability:

Scalability refers to the capability of an application to handle large concurrent requests. There are two approaches generally used to scale an application:

Scale Up: Scaling-up is process of upgrading the existing computer. For example, you can upgrade your Server computer from a 4 processor machine to an 8 processor.

Scale Out: Scaling-out is the process of adding additional computers. This ways if a server reaches its maximum number of requests, another server takes up further requests. SaaS solutions generally use Scale out. A Common techniques used for scaling out is clustering.

Scaling an application can typically be done at 3 levels: