More and more, companies are going to SaaS (Software as a Service) solutions. They offer a quick and generally less expensive solutions compared to standard software approach. This has been made possible by a standardization of the solution, a mutualization of the hardware resources and a pay as you growth economic model. In a business point of view it is also a nice way to bypass the terrible internal IS and IT services to obtain tomorrow what they dreamed to have since a long time.

Beyond this nice view, even if SaaS sellers expect you to trust them, they only provide services, you should never forget that there is under an hadware and It Ops layer your IS/IT team must review before contracting.

This article, follow a brainstorming we had on this topic and gives some area we should investigate before contract anything.

The following list is not exhaustive and as it is my concern, it only addresses some infrastructure points, there are a lots of other topics to cover that won’t be described here.

SLA

One of the main point of discussion is related to the SLA provided by the SaaS provider. One of the main difference with internal IT is that SaaS provider is generally offering a SLA out of his own datacenter, not going to your end-user. This makes sense as the Internet connection is not part of his responsibility.

Defining the SLA provided is something really important as the rules you can have internally can be drastically different here. It’s important to start re-defining what are the outages, what are the one considered as planned and unplanned. How many of each are part of the contract per month and what is the maximum duration cumulated per month. Then you must also investigate on the way used to measure them and to report them. You should also discuss about the ability you have to measure the availability yourself to compare your indicators with provider’s one.

Don’t forget to defined what means available. Certain services, for example, can concider them as up during a backup period where the system is only accessible in a read only mode. What period of time is consider as under SLA ? imagine the provider doesn’t have a 24/7 team to support his infrastructure he could only accept to measure SLA on opening periods ; in a such case, what is the resolution time depending on periods.

Support

What kind of support is offered by the SaaS provider, what are the open hours, what are the supported languages, where support is located and what king of problem the first level of support can solve directly. What is the average time to get access to a layer two support and what are the contractual response time the SaaS provider can offer. Is there an escalation process defined.

How the support alarms you, pro-actively,  when the service is not available and how do you get updated on the resolution progress.

Change Management

What is the change management process, can you refuse or delay certain change impacting your business process. What is the frequency of these change and the impact on service availability for customers. What is the minimal time you have to approve a change.

Backup

The way backup are done in a SaaS environment can have impact on your future operations : backup are not only used for restoring data in case of infrastructure crash but also to restore integrity in case of corruption, attack or volunteer destruction. In a multi tenant environment you need to ensure the SaaS provider will be able to restore your data without impacting other tenants. You need to ensure you can go back in the past day per day for a sufficient period, depending on your business process and your ability to detect data corruption.

As sometime you can expect to start training or sandbox environment from you production dataset, the ability to restore prod data in such environment is also something to address during the SaaS sourcing.

The way backup are made, cold or hot backup, is impacting the SLA of the application and must be detailed. The existence of archive logs mechanism will also impact the quantity of data loss in case of crash. That’s why, even if you expected to hide all these technical thing by choosing a service oriented solution , you must discuss technical implementation during SaaS project.

Don’t forget to discuss the time expected to get your backup loaded in case of request and discuss backup location. It would be a mess if servers and backup burned together…

DRP

This bring us to the DRP part : what is the provider solution in case of primary infrastructure destruction. What is the backup solution the provider have, how many time does he need to restore your access and what is the amount of data loss during this event ?

You must also consider if this new location will be accessible the same way the previous one : if the DRP site is in another country, you must consider  change in the latency, eventually data export regulation. By changing the site, you could have to reconfigure some access to the SaaS infrastructure like VPN configuration for example.

Does the service provider executes DRP tests and will you be involved in such tests.

Scalability

SaaS is scalable as part of the cloud, isn’t it ? Even if contractually it’s true, beyong the marketing message there are some infrastructure reality and all the architecture are not transparently scalable.  You don’t really have to challenge the SaaS provider infrastructure but you need to understand the rules. When you scale up, the provider could have to move you regularly to move powerfull hardware or it could have to had nodes to your instances. In all the cases, these modifications can require service unavailability or request some delay that could limit your scalability capabilities.

For the same reason, when you scale down, the provider could have to move you to lower infra or can refuse to reduce your bill because he would not be able to reuse the infrastructure in place that can be dedicated to you. The contract must precise all these mechanisms.

Another point concerns the ability to scale geographically. Imagine you need to deploy the service in different zone, the latency of the data regulation low could limit your ability to use a central hosted service. The provider, in this case, must be able to offer you solutions and you need to ensure his ability to do it. This can requires different instances and can impact you business model.

You also need to ensure you will be able to leave your SaaS provider if any major change in his infrastructure like DC localization impacts your performance or more generally your business and its security.

Reversibility

What about leaving your SaaS provider ? in a classical application context, it is easy to get access to the data you own in your database and provide them to a third party for integration in a new solution. In a SaaS environment you must ensure you will be able to extract your data, easily, automatically and in an open standard you will be able to reuse. This must be clarified at the beginning of the contract and you should execute it to ensure you will be later able to reuse these data. You should requires to obtain the data model associated to this export. It has been seen in certain solution the ability to export your data by doing 1 click per data to extract which makes it not usable.

Prerequisites

As any software, SaaS is coming with desktop prerequisites. As the technology is generally based on thin client, they are not complex to provide, but the SaaS provider choice can differ you company standards. Some could request certain version of JRE, Flash, PDF ; refer a browser to another like IE or Chrome … The main mater is that these prerequisites can change years after years and can make your internal infrastructure not able to access the service correctly. If you can’t really imagine to force them to go to your standard you need, during the initial discussions, to limit the ability to change the prerequisite and request delays before accepting any change, time for you adapt your infrastructure to the new requirements.

This may concern main change like browser brand, but also small change like JVM update as changing from 1.6 to 7 for example can impact other application than the SaaS itself and take time to be validated.

This is also valid in the other way for security fix application : your SaaS provider can’t force you to stay to much on a non secure version of browser, JVM… You need to ensure they will apply patch  in a reasonable time to protect your infrastructure and to let you time to do the required changes.

You could imagine to describe different awareness delay depending on the element concerned, like for an OS support change, your company may need multiple years to move to, but for a subversion of JVM it can be a couple of days/weeks.

These change could also be a good reason to move out from the SaaS and part of some contract cancellation.

User Management

You generally already have an enterprise directory used to identify your users. The SaaS can be interfaced with it but it depends if you can provide standard sso service from your directory. When it is not the case, the SaaS will push you to manage another directory, specific to this service, including all the process around user creation, deletion, access rights and support (like password loss). These  processes can be time consuming and are generally already sized for standard software solution. The overhead needs to be considered in the TCO study.

To conclude

Do not consider this article as finished, it is an open topic and the role of it is to point on the fact that contracting a SaaS is not only a business stuff, it needs to involved IS/IT team to ensure the quality of the service provided correspond to your internal standards.

Feel free to comment this article and add your personal experience of SaaS services.