I just opened my mailbox to one of those LinkedIn notices, this time pointing me to recent discussions from the CIO Network (which is a really interesting group, btw). I found the thread starting with "I am planning to use a software of SaaS vendor. What concerns do you have when you want to use SaaS software in public cloud?" to be really fascinating. Here's a running commentary...

Respondent #1: "Security is a very big concern for companies that are planning to use SaaS. You need to plan beforehand for the data that you are planning to put in the cloud thru the SaaS application. Would your organizational policy allow that data to go outside the organization...I would say this is not a vendor issue, most of the vendors have very high level of security certification, it is your organization that may limit your options for SaaS.

Respondent #2: You certainly want to be sure that the SaaS vendor has a good track record, been in business for many years, no history of security breaches, multiple data centers and a history of vey high availability, backup and recovery sites outside its own daya centers...

Footnote - what proportion of SaaS vendors can reasonably be expected to meet this threshhold? The "SaaS" vendors clearly can't - they don't generally operate multiple data centres, and if you go only with those who have been in business for many years, you'll miss most of the innovation in this space. I believe what R2 is looking for is SaaS that is rooted in a PaaS/IaaS platform managed by one of the major hosting companies - AWS, Microsoft, IBM, etc. - which is a fair requirement, but a little different, I think, than what might be gathered from a SaaS-specific interpretation of the comment.

Initial poster (IP): "My vendor is using the Google Cloud service, so we can trust them about security and data availability, can't we?"

R1: "As I said security is not a vendor issue, you can trust them about security."

Footnote - wait a minute - "you can trust them" is not a reasonable approach to cloud SLAs!

R3: "What type of SaaS s/w you want to use and what is the purpose?" Footnote - that's a very important question, R3!

IP: "The purpose is to reduce the IT Headcount and reduce cost by outsourcing Infrastructure as IaaS We have many applications here but I want to move one by one. Maybe first one is Accounting software or Sales Management software."

Footnote: It's great that IP has clear objectives, but our research has shown that it's a bad idea to start a cloud strategy with a mission-critical app (start small, understand the platform first), and that most companies are hesitant to move financials to the cloud even after they gain some experience...

R4: "IT Security is main one in SaaS Risk Mgt, here is the checklist following a security audit from an Australian gov agency (Defence Signals Directorate), they defined 51 checks..."

Footnote - this is a helpful post - follow the links, and you land here: www.dsd.gov.au/publications/Cloud_Comput...y_Considerations.pdf

R5: "Security is always an issue, and not so much a threat from some unknown source, but internal to the SaaS provider. Secondly, if your application has a lot of integrated components or will require custom tailoring, you'll need to be prepared for the costs of making changes unless you've negotiated changes as part of the contract. SaaS providers will pitch you the simplicity of going with their solution, but once you're locked into a contact, they will nickle and dime you for everything from making changes to data extraction." Footnote: R5 is my hero - I want to hear more from R5!

R6: "It sounds like you need a place outiside of your company to host your accounting and sales software, if this is teh case then you don't have to have a SaaS provider, you can just move your servers with the apps and data to a host provider...You also mentioned that you have many applications, you may have to start developing an enterprise architecture first and do some kind of application portfolio rationalization; prepare an inventory of all the applications, develop a business capability map and relate the apps to business capabilities that they are supporting; at the end you will see duplicates applications, unwanted applicatione etc that you may not have to even move into a cloud. Footnote: R6 is a hero here, too, stepping up with the unpopular but true notion that cloud isn't a silver bullet, and that some hard set-up work is needed to get benefit from a transition, regardless of the direction it takes.

R8: "How do you get your data back if you stop using the service?
How long would it then take you to move the data over to the service that replaces it? What's the penalty if the company doesn't keep their SLA? How often can you get a backup copy of your data?" Footnote: Okay, R8 works for SFDC, so there's a commercial agenda here - which shouldn't override the fact that he's right...

R9: "Focus on three areas. How will you control your data (can you get usable backup copies). How will you be able to link SaaS systems with internal systems (bi-directional data flows). How can you be sure the security is real and consistent." Footnote - R9 is right, too. At this point, IP must be getting a sense that a cloud migration might entail quite a lot of work, and likely, a fair amount of professional services support for that work.

R12: "In addition to performance concerns, I highlight the following as important considerations because they are simple, technical solutions that any SaaS vendor can implement and which prevent potential business and legal problems:

• You retain exclusive legal ownership of your data
  Your data is stored in open-source formats (so you can easily migrate away)


• The vendors privacy policy *and data retention policy* is in keeping with your company's own


• The interface(s) to the SaaS are strongly encrypted


• Data stored with the vendor is encrypted by default


• The access rules to the SaaS mirror your users' need to access information


• Whenever possible, choose a SaaS vendor that uses the Affero GPL


• You make frequent backups to an in-house, encrypted server for "just in case" problems"

End note - this discussion goes on for pages, taking a path that includes extensive discussion of licensing terms and issues. Highly recommended! Here's the link.