In this article, our business focus is featured as a long running trend within Internet industry.

From LaNacion.com, 2011-09-04. Link to the original article.

Back in the desktop software era, magazines ran software reviews in which the side-by-side comparisons of features took up an entire page. Buyers used these reviews to shortlist vendors, trying to anticipate which features they’d need over the next five years. Typically, the software with the most features won. Feature-itis ruled.

The point here is that the initial feature set didn’t matter much. Indeed, in order to evaluate SaaS, those page-long feature comparisons can be whittled down to just seven critical questions:

1Adaptability: How easily can you modify the application? This can be as simple as adding fields or building dashboards, or as advanced as a programming platform.

2Reliability: How much can you depend on the system to function well? This boils down to four things: Performance, availability, scalability and security.

3Task productivity: How effectively can your users accomplish their goals? How many cases-per-minute or entries-per-day can workers do, and how many errors do they make?

4Price: How much will it cost — really? Because SaaS offerings are so varied in pricing, it’s hard to compare them. A better model is to create several benchmark subscribers (a 10-, 100-, and 1,000-person organization) and compare upfront and ongoing costs for them.

5Back-end integration: Can you plug it in to other things? Any enterprise SaaS offering will have to work with other systems, for everything from authentication to data sharing.

6Longevity: How long will the SaaS company be around, and what’s your exit strategy? With ISVs, you could ask for software in escrow. But as the sudden disappearance of Coghead shows, when a SaaS provider closes down, your entire IT systems can vanish with the flick of an “off” switch. Offers from Intuit and others to help stranded customers notwithstanding, this is a big problem.

7Ecosystem: How many third-party developers and integrators surround a particular platform with plug-ins and add-ons, and how active are they? A vibrant ecosystem means a more extensible, flexible solution.

The key point, however, is that features on day one don’t matter as much as the efficiencies and cost savings you can squeeze out of the SaaS tool within 30 days of adoption — and how confident you are that those efficiencies and cost savings will endure.

Source: Gigaom.com

Introduction

Software as a service. The words are on everyone's lips. The pages of software industry publications are full of articles about software as a service (SaaS)—articles that use words like "revolution" and "horizon" (as in, "on the…"). Everyone knows (or thinks they know) what it is, roughly, and everyone knows it's going to be big. Yet few people would say they can really define it, and even fewer know how to build it.

So, if SaaS holds such promise for the future of application delivery, why isn't there more guidance available to help people actually achieve it?

For this to happen, though, software vendors need resources and information about developing SaaS applications effectively. This is the first in a series of papers from Microsoft dedicated to demystifying SaaS and providing practical, real-world guidance for architecting SaaS applications. This paper serves as an overview of SaaS, its challenges, and its benefits for those who are interested in offering SaaS. Future papers will explore many of these topics in detail.

This paper begins by asking just what software as a service is, exactly, and it explains the conceptual shifts that prospective SaaS vendors must experience in order to understand how it differs from traditional, on-premise software. Next, we'll look at the SaaS business model, to see how software as a service can be monetized in the real world.

Because this is an architectural paper, the largest section addresses the architecture of a SaaS application. We present a four-level maturity model that explains and puts into perspective some key attributes of SaaS: configurability, multi-tenant efficiency, and scalability. We'll examine the components of a high level SaaS architecture, and then take a closer look at a typical challenge the SaaS architect faces—that of providing a mechanism for extending the data model of a multi-tenant application.

Lastly, we'll take a brief look at some of the operational issues involved in supporting a SaaS application after deployment.

What Is Software as a Service?

Even today, the exact definition of software as a service (SaaS) is open to debate, and asking five people would probably result in five different definitions. Still, most experts would probably agree on a few fundamental principles that distinguish SaaS from traditional packaged software on the one hand, and simple websites on the other. Expressed most simply, software as a service can be characterized as follows:

Take a moment to consider the implications of this definition. It doesn't prescribe any specific application architecture; it doesn't say anything about specific technologies or protocols; it doesn't draw a distinction between business-oriented and consumer-oriented services, or require specific business models. According to this definition, the key distinguishing features of software as a service are where the application code resides, and how they are deployed and accessed.

(Is this definition a little simplistic? In a word… yes. Later, we'll focus on some of the attributes that define and distinguish a well-designed, mature SaaS application.)

By this definition, SaaS includes a number of services and applications that you may not expect to find in this category. For example, consider Web-based e-mail services, such as Microsoft Hotmail. Although Hotmail might not be the first example that comes to mind when you think about SaaS, it meets all of the basic criteria: a vendor hosts all of the program logic and data, and provides end users with access to this data over the public Internet, through a Web-based user interface.

Moving from the general to specific, we can identify two major categories of software as a service:

• Line-of-business services, offered to enterprises and organizations of all sizes. Line-of-business services are often large, customizable business solutions aimed at facilitating business processes such as finances, supply-chain management, and customer relations. These services are typically sold to customers on a subscription-basis.
• Consumer-oriented services, offered to the general public. Consumer-oriented services are sometimes sold on a subscription-basis, but are often provided to consumers at no cost, and are supported by advertising.

This paper focuses on the architecture and business issues involved in developing line-of-business applications, and the concepts and examples herein are presented in that context. However, issues such as multi-tenant customization and extensibility, data scaling, and isolation issues also occur (and in fact tend to be easier to resolve) in the consumer space, so developers of consumer-oriented SaaS offerings may benefit from reading it as well.

More info on the original Source: Microsoft, "Architecture strategies for catching the long tail". April 2006.