Tuesday 9 November 2010

SaaS Cloud Computing – Selection Tips

SaaS cloud offerings vary greatly in standards. Depending on the specific application (app) and how business critical it is, it's worth carefully considering the following aspects of SaaS before you select a system:

Functionality – As with on-premise systems, establish overall context of a system and your key needs from it. Even if you can do free trials, assess breadth of functionality and other aspects of offerings carefully alongside trialing. Take nothing for granted. A formal specification is worthwhile, even if very brief, to provide the vision for selection and subsequent implementation

Time to Implement – Selection and acquisition can be quicker, but implementation itself is likely to be comparable to on-premise systems due to similarities in data conversion, change management etc. See selection and implementation processes.

Pilot Testing – SaaS is typically cheaper and easier, and less embarrassing to stop and try another system

Remote Access – It’s you as the customer that has responsibility to ensure adequate contingency arrangements for internet access at each location, including home workers. Is what you can arrange adequate for this application?

Backup, Recovery and Disaster Recovery – Typically far better with SaaS, but: (a) What backup exactly does provider do? (b) What is their policy for recovery? Can they just recover your/another's data if only yours/another's gets screwed, or does it have to affect everyone?

Location of Servers and Backup Servers - Establish current server locations, physical security, and provider's rights to change locations. Assess Data Protection Act and other legal/regulatory issues in each territory

System Availability - Any contractual SLAs (service level agreement commitments)?

Access Security - In addition to username + password, is there some extra method(s) such as PIN, memorable question, etc? If important to you, is access logged and auditable?

Encryption - Is data being sent to/from the server encrypted? Also consider whether data can be encrypted on the server, if you need it

Integration with Other Systems - Take nothing for granted - check need for integration, availability of capability in and out, and reliability

Configuration (using end-user functions) - Establish what you can change and what requires help from the provider e.g. VAT rate change

Customisation (additional custom-programming) – Not usually available within the app, but extras may be bolted on. If you require customisation now or possibly later, understand the options.

Upgrades - Is there any control over timing of upgrade? e.g. do you have a separate database, and/or are you given say 2 months to upgrade after new release becomes availabl

Upgrade Testing & Update of User Procedures - Does provider allow you to view/test a new release before it goes live? If so, can you use a copy of your data, to test transactions that are part-processed? How good are the release notes in detailing every change, not just new headline features?

Training Environment - Does provider allow additional space into which your live setup (and possibly data) can be copied for training purposes?
 
Purchase Cost – Typically monthly OpEx rather than up-front CapEx. But there may be a lump-sum payment up front, especially for the more sophisticated systems that require pre-sales consultancy

Adding Users – Usually easy but understand any minimum timescale commitment

Administration Time/Cost – Typically lower, but not zero. Still have admin of set-up such as leavers and joiners, plus fault resolution and management of provider


End Of Use (termination of contract) - Ensure you legally "own" data and there are tools to extract a copy in usable form whenever you require.


Supplier Financial Stability – Lower payments put additional financial strain on providers. Establish all parties in provider supply chain, back to hosting provider. Demise of any one of them could mean service withdrawn sooner rather than later. Check financial status of each party in supply chain.

If Provider Goes Out Of Business What safeguards does the provider offer, given the various members of the supply chain? Is it worth using two different systems in two parts of the business, with a tested transfer routine, so you can quickly switch systems if provider goes out of business? Or should you have a second system on stand-by on minimum subscription?

Control of Systems – It can be a relief to put your systems in the hands of an “expert” provider. But unless you are an important customer you will have little if any influence on commercial terms or day-to-day running. Understand sophistication or provider, and consider control issues.

IN CONCLUSION

As you assess each of these aspects, by comparison to equivalent aspects of any new or existing on-premise options, you can better assess whether each SaaS offering will be acceptable. Even an imperfect SaaS offering may be a lot better than the on-premise alternatives!

If in any doubt, do contact us.

.

No comments:

Post a Comment