SaaS Buyer’s Guide – Technology Considerations

By Subraya Mallya on 02 March 2009 | Topics - SaaS

I covered the high level topics that you as an IT executive responsible for procurement of a SaaS solution need to keep in mind while choosing a SaaS vendor.

In this post I will cover the Technology considerations to be made while choosing a SaaS vendor.

As in the case of traditional software solution, identifying and establishing the match of business needs with the software capabilities will  obviously be the foremost consideration.

This is where one of the biggest contradictions comes into play. SaaS business model, by its very nature, requires companies to keep the cost of sales/customer acquisition  low. This would mean the salesperson will try to close the deal with minimum investment and fast. At the same time your interest should be to do all the necessary due diligence while making the decision. Beware of the “it is low risk what have you got to loose” tactic. To ensure that you don’t end up with a long road of frustration, that is a common place dealing with software vendors (yes, this coming from someone who has spent all his life building software) this is what I recommend.

  • Evaluation: Expand the scope of the product demo (by vendor salesperson) to be followed by a evaluation period. Insist on a minimum of 15 days of evaluation to give your team enough time to do the necessary crosschecks.

As part of the evaluation, include the following activities, at a minimum.

  • Feature set: Have your business users do a deeper dive into the product capabilities and cover all the critical areas promised by the vendor’s salesperson. Nothing like seeing it for yourself.
  • Availability: Have business users from different geographies within your business test the application from their remote location. This will ensure application will provide the requisite performance and does not impact productivity once deployed. Specifically pay attention to those telecommuting employees who will access the application. Accessing from a office on a T1 line is different from accessing the same from a cheap DSL line. Even if the SaaS vendor does not certify against slow DSL access, this will give you an idea to plan for potential expense item for either higher speed DSL or cable internet access to ensure there is no productivity loss.
  • Internationalization/Localization: Most SaaS companies have originated in the US and few have a really strong user base outside. If you are global company, and have a non-english speaking employee from a different geography verify the capabilities around Internationalization and Localization.
  • Customization/Personalization: SaaS delivery model at the outset discourages long drawn out customization phase that has long been the pain with on-premise solutions. That said, your business process might still not be adaptable to the software delivered out of the box. So it is important to evaluate the abilities provided by SaaS vendors for customization, albeit lightweight.
  • Browser Support: Given that most SaaS applications would be browser-based, incorporate Cross-Browser Support in your evaluation.

It will be challenging to get the team assembled to do all this in a short duration while you are still running a business but trust me every minute spent here is well worth it.

Note: One thing to keep in mind right during the evaluation  is, most SaaS applications will cater to the 80% needs that are common across companies. So it should not come as surprise to you if you find certain company specific needs not met out of the box. Don’t get bogged down by that.

Once you have the go ahead from the business community, you will want to ensure the SaaS solution aligns with the other IT standards you might have established in your company.  Remember as IT, your team will still be the conduit in delivering the solution and service levels to your business despite the solution being outside your control. Here are the key things I would look for from a pure IT point of view.

  • SLA: Request and Review the Standard License Agreement with Service Levels clearly outlined ahead of time so when it comes to contract negotiation you give yourself sufficient notice. Pay attention to the Service Credits that you will be owed in case of the vendor not meeting the Service levels.
  • Scalability: Review the architecture for accommodations made to address the scalability needs via redundancy. Ask for benchmarks done for scalability in terms of data volumes and user loads. Better yet ask for reports that indicate the scale over time and overlay it with availability.
  • Integration Adaptability: Review the integration capabilities. Given that SaaS is in-cloud, having a comprehensive architecture to support integrations for your company to close the loop with your existing applications is critical. I would specifically check for standards based data adapters available in the form of Web Services. Given that most companies still have legacy/homegrown applications that might not be web services conversant,  you might also need a CSV based adapter combined with secure FTP capability.
  • Ecosystem: Deciding and buying a software (or a service) is a commitment. Lack of vendor lock-in argument notwithstanding. Once a enterprise makes a commitment to a software and gears its IT/Business workforce to work with it, it is almost impossible (never say never) to switch to another along the way. So while making the decision it is important to ensure the technologies used by the vendor are open, standards-based and has a good community following. Without that you will be at the mercy of the vendor for all the customizations and also not be able to hire/retain employees with those skills.

In the next post I will cover Governance related topics like Disaster Recovery, Audits, Change Management,  Backup, Recovery and Retention (BBR) Policies, Security infrastructure and processes around Monitoring, Provisioning, Identity Management and Data Reclamation.

Back to Top