December 4th, 2006

Seeking the true meaning of SaaS

Posted by Phil Wainewright @ 7:48 am

Categories: Web 2.0, Web 3.0, basics

Tags:

TalkBack

• Print
• Email
• Thumbs UpThumbs Down
• +19
  19

As has happened with so many terms in the IT industry, the definition of software-as-a-service, or SaaS, has been stretched this way and that as vendors compete to make marketing capital out their use of it. As the model evolves, some vendors on the leading edge are trying to redefine SaaS more narrowly in order to exclude their more laggardly brethren, but the tactic is doomed to failure. The more exclusive they try and make the bandwagon, the more appealing it becomes for others to leap onboard.

The truth is that SaaS is, and always will be, a very broadly defined term, and therefore it’s inevitable that there will be many different subcategories of SaaS. That creates plenty of potential for misunderstanding and confusion, of course. But don’t worry, there’s an easy way to avoid getting bogged down. The key to making sense of SaaS is see it in terms of the journey a software developer or architect might take as they plunge further and deeper into the SaaS model. At the outset, the product they’ll create looks very similar to conventional licensed software. At the end of their journey, it may not look like software at all. That’s the extent of the spectrum that SaaS covers. No wonder people often have difficulty categorizing SaaS or making comparisons between SaaS offerings. If they’re dealing with different ends of the spectrum, there may be no useful comparison to be made at all. So let’s embark on this journey and map out where it leads.

In the beginning
We begin with the two essentials of Software-as-a-Service: hosting and subscription. This is the starting point. The software runs on the provider’s premises, not the customer’s, and payment is by subscription spread over the term of the contract rather than as an upfront license fee. There are some basic advantages that flow from taking this initial step, mostly to do with amortizing the cost of acquiring, implementing and operating the software, especially if elements of those costs can be shared across more than one customer, yielding economies of scale. The lower initial cost and the relative ease of implementation on the provider’s ready-made infrastructure mean that this can still be an attractive model in certain customer scenarios. But the advantages are rather limited, which is why application service providers, who pioneered this model mostly in 1999/2000, failed to make much headway.

The breakthrough comes from recognizing something I’ve been telling people ever since the summer of 1999, when I stood up on stage as the opening keynote speaker of the first-ever ASP conference: “This is more than just a relocation exercise.” Once you move software off the customer’s premises and host it in the cloud, a whole new range of possibilities begins to open up. The journey I’ve mentioned is a journey of discovery, in which those possibilities gradually reveal themselves. Over the next few pages, I’ll set out some of the most important revelations to be found along the way.

Shared instance/multi-tenancy
I’m not one of those purists that holds that you can’t have a pure SaaS implementation unless it has a completely multitenant architecture — in any case, as Microsoft’s Gianpaolo Carraro and Fred Chong have shown, multitenancy comes in several different flavors — but I will say this: it helps. Multitenancy in SaaS (ie having more than one customer running on a single unit of live software) is a bit like grammar in language or harmonics in music. It’s OK to break the rules, but only if you’ve first embraced them and really understand the consequences of going against the grain.

Unfortunately, there are countless vendors out there who haven’t yet reached that level of awareness. Many of them are holding back from multitenancy because they’re saddled with conventional software code that isn’t architected that way. It’ll take them time and a massive re-engineering effort to switch (if they ever manage to).

In the meantime, there are still huge benefits to be gained at various stages on the journey to true multitenant nirvana. The most important is that customers don’t have to wait for a custom technical implementation. With conventional on-premises software, there’s a substantial timelag after purchase before the software is ready to run. With SaaS, the software is already up and running in the vendor’s data center in advance. This has an enormous impact both on the customer’s exposure to risk when getting started and on the vendor’s business model. Having the software already operational means that customers can go live in a matter of days or weeks, and they’re free to phase in the roll-out to cause minimum disruption to business operations. Vendors can offer try-before-buy trials and demonstrations at little or no cost, and there’s a low overhead to adopting an iterative style of implementation in which a pilot group of users can test the look, feel and structure of the application and give feedback before a full production roll-out begins.

Ideally (and this is a key stage in the journey to multitenant enlightenment) the provider’s implementation is a ‘black box’ to the customer, who has no interest in the underlying technology so long as the contracted outputs are being delivered as specified. It’s the provider’s business to tune the infrastructure to provide the best combination of performance, economy and management. The customer’s only concern is to get maximum utility out of the service provided, not to interfere in the provider’s technology decisions.

Astute readers will have realized that what I’ve just described conforms exactly to the principles of service-oriented architecture (SOA), and it’s no coincidence that those SaaS vendors who’ve embraced multi-tenancy have also embraced SOA. This leads on to important side-effects, such as enabling policy-driven configuration of applications as a means of customization rather than the custom coding favored by conventional software vendors. Multitenancy obliges vendors to push the envelope of SOA because their customers want the flexibility to modify how the applications work for them, even though the underlying software code has to be the same for everyone. SOA provides a framework for separation of concerns that can accommodate these apparently conflicting needs. A further benefit of using policy rather than code to modify the application is that it makes it easier for business users to control the application’s functionality and processes for themselves. This further enhances the capacity to deliver the business results the customer wants to achieve.

Shared services
Once your software becomes a service in the cloud, it opens up the potential to link it up with other services that are out there. For many vendors and users this is still a barely dawning realization, but it’s of fundamental importance. In many ways, the Internet cloud is one great global SOA — still very rudimentary in many ways, but flexible enough to accommodate different levels of sophistication, and evolving fast.

Leading-edge SaaS providers use the Internet not only as a delivery mechanism to deliver their services to customers but also as an aggregation platform to enhance and extend their own capabilities by linking up with third-party services. A good example is longstanding HR provider Employease (now part of ADP), whose infrastructure includes connections to 3000 back-end partners providing a range of specialist services such as payroll processing, insurance and 401k schemes, compliance and so on. If Employease were a conventional on-premises software vendor, each of its customers would be obliged to forge every single connection for themselves. As a SaaS provider, Employease only has to make the connection once and it becomes a shared service, instantly available to any of its customers. The same principle can be seen at work in Rearden Commerce or Salesforce.com’s AppExchange.

Understanding the implications of shared services in an Internet environment is a further step on the road to enlightenment. It extends the horizons of SaaS providers beyond the confines of software alone, opening up the potential to connect to online providers of all kinds of business services and offer customers a complete, finished business result rather than simply a software toolkit.

By the way, it also puts SaaS at the core of present-day trends towards collaborative services architectures both within the enterprise (SOA) and beyond it (Web 2.0/Enterprise 2.0). Every Web 2.0 venture is already a convert to this vision of Internet aggregation and delivery. In many ways it is the software vendors who are doing the catching-up.

Community of interest
SaaS vendors soon discover that delivering from the cloud changes the nature of their relationship with their customers in a variety of ways.

The most immediate change is their ability to constantly monitor their customers’ usage of the application. For one thing, this makes technical support a great deal simpler, because there’s no chain of ‘Chinese whispers’ as problems are reported back via helpdesks from the user to a support expert. Instead, the support person can take a direct look to see exactly what the user is doing. But this insight into user activity is even more useful at an aggregate level. It means that customers can evaluate their software and services based on what they see customers using, and then use those metrics to improve its usability, performance or functionality.

More recently, vendors have begun to realize that they can also leverage that global view to provide feedback to their customers on best practices, or allow customers to benchmark themselves against their peers. The aggregate view gives them insight that wouldn’t exist if each customer operated their own separate on-premises implementation, and by sharing the benefits of that analysis with their customers everyone can gain.

Since all customers access the application via the vendor’s website, it’s only natural that online user communities tend to thrive, since the vendor can promote the community and highlight recent discussions or useful material within it. Users can exchange best practice tips about how they use and configure the application, as well as sharing, exchanging or even marketing templates and other add-ons.

Underlying all of these changes is a convergence of interest between customer and vendor that’s more intimate than that experienced in the world of conventional on-premises applications. Perhaps it’s because SaaS vendors are able to move away from the conventional software sales process, where the need to close a big-ticket software license sale before anything else can happen encourages vendors to over-promise and under-deliver, thus breeding customer distrust. Or perhaps it’s because the continuous online relationship of the SaaS environment simply makes it easier to focus on making sure the product is working for customers in their day-to-day use of it.

Pay-as-you-go
I’m not going to argue, as some do, that the pay-as-you-go model of SaaS vendors means you’re free to walk away at any moment. Don’t be misled: vendors are still trying to tie you in to their service just as tightly as conventional on-premises vendors. Although the cost and timescale of implementation is substantially lower, it still requires an organizational commitment to get started with any software application, whether it comes over the Internet or in a shrinkwrap package. SaaS vendors know very well that by the time you’ve made the investment of time, effort and process design required to implement the service and start getting a return from it, you’ll be reluctant to contemplate giving all of that up and starting again.

But the need to engage you in those vital early months changes the vendor-client relationship and creates a powerful incentive to show early results. Subtle changes that SaaS makes to the software vendor business model — flowing from factors such as the ability to provide a fully functional pre-sales demonstration, and the tendency towards an incremental approach to adoption — increase the pressure on vendors to ensure their applications make it as easy as possible for users to get started and show early results.

Pay-as-you-go also means customers pay a single, known monthly amount for a functional service, instead of the various lump sums and annuities associated with conventional licensed software — licensing, maintenance, support, and so on, most of which are paid irrespective of whether or not the software is working as intended — along with additional internal costs incurred in maintaining the technical infrastructure, which are often under-measured.

Putting everything onto a single monthly bill that’s paid in exchange for delivery of a functional service makes it much easier for customers to see exactly what they’re getting for their money, and ties in better with service level agreements that allow customers to choose between differing levels of service quality, depending on budget and willingness to pay. Those vendors furthest along the path to enlightenment also see that it is their passport to participation in the emerging “business web” of interlinked Internet-based services, whether as an aggregator of third-party services or as a provider themselves of services to other aggregators.

 

I hope I have helped illuminate at least a part of the software-as-a-service landscape. Of course there are several more landmarks that I could have mentioned, especially on matters such as user empowerment, composite applications and processes, the relationship to open source and the role of partner ecosystems. Think of this merely as an introduction to the key points. It’s based on some notes I’ve been making for a report that I plan to publish early next year, and may at some stage expand into a white paper. It also draws on ideas that I first elaborated in a couple of reports on ’software-powered services’ that I wrote two years ago for Summit Strategies (now Ovum Summit).

One closing point that should have become evident by now: SaaS is inadequate as a term to describe the end destination of this journey, which is both less than SaaS, by virtue of what it leaves behind, as well as more than SaaS, on account of what it gains from connecting into the collaborative Internet. Alternative terms already exist — I prefer to talk about on-demand services — so I don’t think we need a new buzzword. Essentially, this is just a new spin on business services, which is something we’ve had since before the advent of the Internet, or even of computing itself. It’s business services, automated by software and connected up by the Internet. Funnily enough, some of its early pioneers once formed themselves into an industry body called the Internet Business Services Initiative. Evidently they at least have always had a good idea where they were headed.

Phil Wainewright is a commentator and strategist on emerging software industry trends. See his full profile and disclosure of his industry affiliations.

Email Phil Wainewright

Subscribe to Software as Services via Email alerts or RSS.

A simple but effective description of what SaaS or Cloud Computing can be defined as or the services that it encompasses.