Bringing SAAS Model allow it to outlast an earlier cousin, the "Application Service Provider" leaving a modest room for the marketers how to claim it is. The big question for SaaS may be this: Will it impel the concept of cloud computing, or merely ride on its beckon?
Although the industry acceptance of SAAS is very high, it has its own pros & cons as well..
Recent predictions from Gartner show around 30% of the enterprise revenue being generated by Content & Collaboration applications itself.
The market feedback in brief as per Gartner:
To succefully implement SAAS model for an Enterprise Solution, the strategy has to overcome these recedes.
SAAS-ified
Infact the SAAS & Cloud Computing work in tandem, Cloud enables SAAS at infrastructre level while SAAS provides the way to Agile licensing. SAAS-fication of a solution happens at two stages, viz.
1) Application
2) Infrastructure (that runs the application)
To make applications SAAS enabled, typically application framework has to be modeled with IOC (Inversion of Control). Entire application has to be meta-data driven. Sounds like a purely multi-tenant application.
Contrary saas enablement of Infrastructure happens with leveraging Virtualization, that brings all the characteristics of the classical Cloud Computing architecture.
Benefits
• Tenancy – The ability to distinguish one user from another in the data and execution aspects of a hosted application is a major tenet of SaaS. Generally, the concept of tenancy is void in traditional on-premise installs and can complicate architectures beyond what was traditionally accepted.
• Flexible Monetization & Metering – Being able to charge for your SaaS application independent of the software code, and meter it appropriately, is something that your application shouldn’t have to deal with directly.
• Scalability – The idea that a successful application will buckle under its own popularity is never good. Being able to accommodate your aggregated customer base is a must, and planning for success is a requirement.
• Reliability – What good is a SaaS application that isn’t up?
• Hardware Infrastructure – As a vendor, one of the operational headaches of SaaS applications is dealing with an enterprise-grade hardware infrastructure.
• Value Added Services – A good platform should endow the application it hosts with value beyond what was developed by the vendor. The value should either benefit the vendor or the end user.
• Ecosystem – As the number of vendors that host their applications on a given platform increases, and as the number of users using those applications increases, an ecosystem begins to develop. Ideally, this ecosystem allows all parties the ability to investigate and exercise their right to connections between ecosystem members, deriving value beyond that offered by any single SaaS offering.
• Faster implementation: Customers deploy within hours with Sonian and integrate with their existing systems. ather than weeks or months.
• Intelligent and Infinitely Scalable Computing Resources: Sonian’s use of cloud computing allows our archiving service to automatically throttle up or down computing resources depending on your requirements. This process provides our customers with an amazingly fast search and user experience.
• Infinitely Scalable Storage Resources: With Sonian, you never have to worry about running out of disc space or paying more for storage. Because of our use of cloud infrastructure Sonian provides unlimited storage to our customers.
• Little or no upfront fees: [agile licensing]Avoid paying for the acquisition and licensing of hardware and software
• Lower Total Cost of Ownership: Costing 7 to 10 times less than installed software and hardware.
• Leave it to the experts and Reduce the Burden on IT: Take advantage of experts in email archiving, indexing, search and discovery. Your IT staff have tasks that challenge them and keep them happy.
• Regular upgrades: Receive regular upgrades to enhance your user experience. New functionality is yours when you want it with no additional fees.
• Safe and Secure: DoD encryption and PCI-DSS security standards and unlike other SaaS archiving providers, Sonian provides a private data silo for you and your company.
• Fast and Reliable: Return search results in under 3 seconds regardless of the size of your archiving
• Availability and Redundancy: Sonian’s use of the Cloud allows our service to take advantage of failure resistant and geographically disperse availability zones.
• No Risk – No Obligation trials available: To learn more about the Sonian Archive Service, please complete the contact form and a Sonian Account Manager will contact you promptly.
SLA
An SLA, as its name suggests, is an agreement between the service provider and the consumers, consisting of sections regarding the various commitments to service levels that will be matched or exceeded.
Each section is defined as a Service Level Objective (SLO).
A typical SaaS SLA should have the following SLOs:
Service Availability – define the availability of the service represented in percentage (e.g. 99.95% uptime)
System Response Time – define response time of various transactions represented in seconds. (e.g. login should not take more than 9 seconds)
Customer Service Response Time – a response on customer enquiries should take no more than an allotted time for various services (e.g. enabling a service for a new group should take less than two business days)
Customer Service Availability – hours of availability of customer service represented in a ‘hours per day’ notation. (e.g. 11X5 for regular customers, 24X7 for platinum customers)
Service Outage Resolution Time – the times it takes to restore a service after an outage has been reported. Represented in minutes and hours (e.g. 30 minutes for a full system outage)
Failover Window For Disaster Recovery - how long will it take to restore the service in a disaster recovery site, if disaster disables the main datacenter.
Reclaiming Customer Data – a commitment to transfer all (agreed) data in an agreed format in case the customer leaves the service.
Maintenance Notification – the advance notice that the provider will notify customers of planned service outages, represented in days. (e.g. a planned downtime that will take more than one hour requires 10 business days notification)
Proactive Service Outage Notification - the time it takes for the provider to inform the customer that there are service issues, represented in minutes.
RFO (Reason for Outage) – a report to customers following a service outage explaining the circumstance, the incident and steps taken to remedy the problem. (For more information see the chapter on Incident Management). Some customers require an RFO automatically; in some SLAs it is written that an RFO will be generated only following a specific customer request. Usually the company commits to three business days following the service disruption.
Approach
The Application SaaS-ification allows to reuse same deployed code-base all over along. This has plenty benefits.
I know, you are thinking for the applications which are already coded and want to leverage multi-tenancy. In sort, how running businesses would rampup by SAAS-ification.case study: multi-tenant alfresco
Planning
Lock-in
1. Platform agonistic
2. Proprietary technology usages
3.
Billing Mediation Simplify the Billing Process
Customer Expectations
Not all SaaS companies are created equal. They will vary by maturity, by the vertical they are serving, by the company size they cater for and, of course, by the type of application.
Some applications are core and some are peripheral. Some applications are used around the clock, like metering or call centers and the customers have zero tolerance for downtime. Other applications are rarely used outside of office hours, (e.g. payroll, talent management) and if the system is down, the price is a handful of irritated end-users that will need to take a coffee break earlier than they planned.
Larger customers tend to have more rigorous demands while lower paying customers will usually be more tolerant of the system’s performance and support availability.
Therefore, your SLA should reflect the relative position of your service along the following three vectors:
Customer size (reflecting subscription [potential] size)
Core vs. periphery
Downtime tolerance
So if you are providing a mission critical application to a large customer, whose downtime will cost the customer real dollars, your SLA should be taken very seriously.
Service Level Breaches and Penalties
We have seen the promises that come with the SLAs, but many of these agreements fail to state the consequences to the provider of not meeting the terms.
Each SLO should also define the penalties for breaching the service level commitment.
Penalties are typically specified as a prorated credit for the following month’s subscription fees.
From the customers’ point of view, the penalties should not be flat rated but increase as the service deteriorates, so that the second outage will carry a heavier penalty than the first outage. It is rare that customers insist on this point but those that do will need to negotiate these terms separately.
There is typically a maximum. It is unusual that accumulated penalties will top the monthly subscription costs. There is a catch here. As an extreme example, if your service was down for the duration of the whole month, the customer will be exempt from paying a full month’s service fee – but this is ridiculous of course. The damage to you customers is typically orders of magnitude higher than the subscription costs.
Many SaaS customers commit up front to a year or more of service, for a reduced subscription price. A good SLA will include a section that allows the customer to breach the extended commitment if the provider failed to adhere to the service levels for, say, three consecutive months.
