Browse by year:
April - 2008 - issue > Technology
SaaS - The emerging model for packaged software
Ramesh Loganathan
Thursday, June 26, 2008
Packaged software offers a relatively low-hassle solution for enterprise business processing. The product vendor takes the responsibility of building the application, getting enhancements and supporting the solution. Eliminating the need to have development teams onboard to build and maintain the solution SaaS, Software as a Service, is taking the out of the box solution model a step further. In SaaS, the software is made available as a service, eliminating the need for even hardware, licenses and production support teams.

In SaaS, typically, a specific application or solution is offered in a managed model with the client just signing up for the solution and accessing it over the web- all operational aspects taken care by the SaaS provider. SaaS provider takes care of hosting and managing the production operations. The Software is either completely hosted or parts of the functionality hosted. The enterprise will just need to sign up and the solution is available- in a traditional utility model, ‘off the tap’. This lets the small enterprise focus on its core business and not have to deal with any aspect of the IT solution operations.

SaaS has been gathering momentum through 2007, fuelled by off-the-web server-virtualization platforms such as Amazon’s EC2 adding momentum to the rapidly gaining acceptance of services such as salesForce.com.

The definitions for SaaS are a bit elusive. Per IDC, SaaS is Software with network-based access to, and management of, commercially available (i.e., not custom) software. Applications or solutions will now be delivered as a managed ‘service’ available for access over the web. The client just asks for it, subscribes, and gets access to the solution. No hardware to buy, no installation or configuration and no administration, monitoring or tuning.

Use cases for Packaged solutions and enterprise applications
The obvious use case for SaaS is end business solutions that would otherwise have been offered as a licensed product that must be procured and installed. For such solutions, SaaS offers a hassle free model. The Independent Software Vendor(ISV) building the solution can now offer the solution in a subscription model- wherein the enterprise client just subscribed to using the solution for a given period. The ISV takes care of getting the required setup and configuration, and the users need simply access the application over the web. No hardware or software to buy. No installation. No configuration. No setup. No maintenance. All aspects taken care of by the ISV.

Enterprises use as much of custom built solutions as there are off the shelf solutions from ISVs. The SaaS model can be considered for custom built software as well. The Managed applications model is slowly gaining traction, where the solution developer takes care of managing all aspects of the solution- development, upgrades, miantanance, patches, support, production issues and more. On a retainer basis for the custom

The typical licensing models are:
1. Subscription: for packaged solutions, software is offered in a pay per use model. No license or hardware purchases needed upfront.
2. Managed applications: here the SI that built the solutions will manage the solution in a SaaS model, for a fixed monthly fee to cover the cost of the dedicated team and resources required to maintain, host and manage the application.

For Out of the box solutions/Packaged products, SaaS offers a relatively low-hassle solution. This will eliminate the need to have development teams onboard to build and maintain the solution. The product vendor takes the responsibility of building the application, getting enhancements, hosting, managing and supporting the solution.

Architecture considerations
As solution architects consider a services model for delivering their software to their clients, different set of challenges come into the solution design and architecture. Ranging from multi-tenancy considerations, to easy configurability, on-demand customization, leveraging virtualization platforms for hosting, and much more.
The key technical attributes of a SaaS solution are:
* Web based access to the solution
* Easily configurable end user customizations
* Centrally managed: Single SaaS team manages the hosting environment for all subscribing clients- rather than each client or clients team managing their app
* Centralized feature updating, which obviates the need for downloadable patches and upgrades.
* Multi-tenanted apps: application delivery that typically is closer to a one-to-many model (single instance, multi-tenant architecture) than to a one-to-one model.
* Including architecture, pricing, partnering, and management characteristics
* SaaS applications are generally priced on a per-user basis. Sometimes with a relatively small minimum number of users, and often with additional fees for extra bandwidth and storage

Typically existing solutions may need to be reengineered for SaaS enablement. These can be at any of the four modes:
* Level 1: Application as is- running on multiple machines
– Zero reengineering
* Level 2: App as is- running on same machine, with one app instances & db schemas per client
– Minimal reengineering. Just to ensure multiple app instances can run on same app server instance
* Level 3: One app instance and multiple db schemas (one per client)
– Requires reengineering to support the notion of multiple clients and client specific db schema switch
– Core app logic remains unchanged- so long as simple db access abstraction available (where the schema switch will be implemented)
– Db structure remains unchanged (other than minimal change to detech user’s company and set
db-schema accordingly)
* Level 4: One app instance and one db schema
– Reengineering of the app and db structure to support the notion of company-id in all data tables and in the functional layers
To get a solution as SaaS, either an existing application has to be reengineered or a new solution has to be built per the enabling best practices. The typical adoption will start from the business need being identified for multi-tenancy and hosted service. The current solution architecture readiness must be evaluated per the above levels. A minimal pilot initiative must be taken to assess the efficacy. To enable scalable service model, the virtualization platforms must be explored. Initially in a minimal reengineering mode, with a basic multi-tenancy approach. Then, one can explore the advanced levels above with more elaborate multi-tenancy. Along with advanced multi-tenancy comes the option to enable meta-data driven end-client configuration and customization. With more advanced virtualization platforms used, the dynamic provisioning for on-demand resources can be explored. The most advanced adoption will be the self-service model where the end user can configure, change, provision additional resources and do more in a self-service portal enabled by the SaaS provider.

Why is SaaS more than ASP (Application Service Provider)
IN the SaaS context, an often asked is if SaaS isnt a new buzz created in the good old ASP (Application Service Providers)? One fundamental difference is ASP is more a platform/data-center service, that can be used to run any application in that data center. They provide production services to manage the application and its uptime. They do not understand the application per se. They are more administrators than solution providers. In SaaS, a solution provider, hosts the solution and makes it available to multiple clients. As an alternative to shipping and installing the software at each client’s site. A SaaS provider could use the infrastructure and admin services offered by an ASP. A SaaS provider is more about building and managing the solution than about data center or infrastructure. They just have an alternate mechanism to distribute their application.

Customizing and extending the SaaS solutions
In most software solutions offered as a service , while bulk of the users will be normal users accessing the solution over the web, there will be a subset functionality required wherein the data or the functionality will need to be integrated with some other applications in the enterprises. The most common usage is for reporting purposes.
Many popular providers allow for some basic customization and extensions (often via Web Services/REST). In 2007, some of the SaaS momentum shifted gears and extended their offerings to include more generic platforms as a service on the web, that allow “building” your own applications on such platforms. Ranging from SalesForce.com’s Apex platform to the due-soon Titan from Microsoft. The former is a generic business process platform, while the latter is a platform to build CRM apps (will possibly include a basic CRM functionality shell which can be used to build your own CRM solution).
In ISV solutions, being offered in SaaS models, generally a good practice to ensure there are APIs as well easy access to business data for non browser based application to SaaS access.

Next frontier- Platform as a Service
As SaaS gains traction, one area to watch is extending the model to one-off custom applications that anyone can get into a ‘service-over-the-web’ model. In SaaS, the onus to get the solution is on solution provider; from reengineering to hosting and managing. A steadily gaining extension is the Platform as a service model. Here any solution, even not in a mutli-tenanted mode, can be made available easily on a hosted off-the-web platform. The virtualization platforms such as Amazon’s EC2 simplify this option, with on-demand OS and application platform availability. The ‘service enabling’ onus now shifts to the platform from the solution provider. This is a front to watch out for in 2009.

Share on LinkedIn