Share via

Defining the Software as a Service Continuum

  • Article

Every now and then, I find myself having “passionate” discussions with colleagues and customers about the definition of software as a service.

In such discussions, the deep geeks like to bring up implementation details like Web services vs. REST vs. AJAX etc.

Then there are the folks who spend time “entertaining” C-level execs by talking about whether software services should only be purely computational or otherwise. The best liner I have heard so far is “Salesforce is not SaaS”. I don’t think anyone in that room was convinced.

While it may seem obvious to many of us who think about SaaS a good part of our wake time, I thought it may still be interesting to share my thoughts about the definition of SaaS as a continuum that is graduated along three dimensions:

 

Licensing:

Clearly, SaaS adds many more licensing options to the perpetual scheme that dominates the shrink-wrapped software market. Subscription, transaction and ad-funded pricing models are all part of the shift that helps lower the initial up-front cost of acquiring software capabilities. In theory, if the SaaS providers take advantage of economy of scale and adopt a single instance, multi-tenant application architecture, the long term cost to SaaS providers for offering their application should be lower than if each individual customer were to license and host the application themselves. In practice, how this provider cost savings actually translate into long term licensing cost savings (or not) for individual SaaS consumer is actually very circumstantial. For instance, if an enterprise already has an efficient IT management system that is hosting other on-premise applications, it may cost the enterprise less in the long run to acquire a perpetual license and operate the application in house.

Location:

Although progress in networking and communications technology has helped mitigate distance factor in the physical world, we are not yet at a stage where both network bandwidth and speed are abundant enough for us to ignore the network latency effects on application performance. At one end of the SaaS continuum, software services are deployed and hosted by a third party and accessed through the Web. Depending on the application and the number of users accessing the application, enterprise may need to factor in additional wide area network access fees to meet the higher Internet bandwidth demand. Smarter application design and implementation in SaaS offerings can also help mitigate the concern due to network distance and pipe size. For instance, software services may be offered through an appliance model. In this model, a pre-configured appliance is leased and installed at the tenant’s site. Normally, data is processed and cached at the appliance to speed up user access. Periodically, certain application data is synchronized with a data hub located at the software service provider.

The location of the service also affects enterprise’s ability to control access to business data and process logic. Normally, with an on premise installation, physical isolation is the natural mechanism for protecting corporate data. When application data is hosted and stored remotely at the SaaS provider, enterprises must now rely on industry regulations, service contract agreements and data security mechanisms and policies at the service provider for protection in lieu of physical isolation.

Life-cycle management:

At this point, I can’t help but think about the Maid Brigade services I use for cleaning and organizing my house. IT management is hard work, just like doing house chores after putting in a 12 hour day.

 

In order to maintain and operate on-premise enterprise-grade applications, corporate IT must develop IT management competency. In addition to being familiar with the network, server and application platform for which the software solution runs and is delivered on, enterprise must also beef up on operational excellence practices for troubleshooting and resolving IT security, reliability, performance and availability problems. Typically, these sets of operational best practices are also supported by another set of infrastructure and management tools for monitoring and diagnosing events and errors, as well as a customer support system for opening, resolving and closing trouble tickets.

 

Because of the above hurdles, some enterprises may see ASP as Godsend solutions to their application management woes. The ASP and enterprise relationship is analogous to the yard maintenance services and homeowner deal. From the ownership and interest perspectives, the homeowner owns the yard and has a desire for a well kept landscape that has curb appeal, delights guests and cheers up outdoor family time. However, if you are like many others who are not born with green thumbs or are time-challenged, the yard maintenance task is best outsourced to professional lawn services. In the same vein, many ASP have data centers that host, manage and troubleshoot applications owned by enterprises.

 

At the other end of the SaaS spectrum, IT management is completely taken care of by the SaaS provider. In fact, the implementation of management tasks and responsibilities is opaque to the SaaS consumers. This is a natural and logical transfer of IT management responsibility as the enterprise does not “own” the application. Application security, availability, performance and feature requirements are established through service level agreements with the SaaS provider.

So the next time someone ask you to define what SaaS means, consider giving him the (high-rise) elevator pitch of the 3-Ls rather than get on your (Web service) SOAP box.

Comments