Losing control of one’s data is among the first concerns that arise when software as a service (SaaS) is mentioned. Fans may point out the merits of applications running in the cloud, but it’s not the software we worry about, it’s what happens, or might happen, to our data. As one Reg reader put it in a recent survey: “I'm sure …
it would be simple enough. If you sign a contract, understand EXACTLY what you're getting yourself into, what happens when the other party liquidates, what penalty clauses you and the other are applicable to, etc..
Just because it's got a funky name like SaaS doesn't make it any less crucial to understand the legalities of what you've agreed to.
Get back to me when ...
... google, amazon, microsoft, facebook, and twitter are all trading "services", in order to save money. Until then, *aas is pie in the sky ... stealing chump-change from chumps.
Stallman was right
Cloud computing *IS* a trap.
It's a tricky business but can be done properly
Being an independent developer I give our clients the option when it comes to hosting: host in-house and bill us by the hour if your people mess up or outsource the hosting to us SaaS-style for a fixed fee and you get your SLA.
Most go the SaaS-route but I'm clear on where the data is, who owns it (the client does), what rules govern the data, allow regular off-site data backups by the client and have clauses in contracts on what happens if our company folds.
Some clients persist in keeping the system in-house, but even those get fed up with internal IT antics and go SaaS behind their backs. Always a laugh when internal IT has a whole list of unreasonable demands (sole ownership of copyright on code, third-party audits) and business goes over their heads, leaves them out of the picture and goes SaaS. As long as the data is theirs they couldn't care less.
I see where you are coming from, but ...
>> Always a laugh when internal IT has a whole list of unreasonable demands (sole ownership of copyright on code, third-party audits) and business goes over their heads, leaves them out of the picture and goes SaaS. As long as the data is theirs they couldn't care less.
That is indicative of a bigger problem, of which the local/cloud is only one element.
Perhaps the requirements didn't actually come from IT, but from management themselves ? I've been there, you see yet another man in a suit, carrying a clipboard, wandering around with a manager and wonder who he is. Then next thing, a list of "instructions" on things we *will* change. Note that in many cases the auditor (whether from the insurers, parent company, accountants, whoever) never spoke to anyone in IT, never asked if there were reasons for doing things the way they were, or what mitigation techniques we might already have in place to deal with a risk - we just get a diktat from management that "we are required to do/change <x>". Never mind if <x> is actually supported by our aged systems, or if it will break something else, or if we've already got the risk addressed - the <whoever> likes to see <x> and so we are going to do <x>.
On more than one occasion I took great delight in doing <x>, having suggested it wasn't a good idea, and then sat back until it started casing problems (such as randomly preventing logins*). Management refused to accept it wasn't a good idea, so we had to do it - and sure enough, it caused problems we'd end up either reverting the change or having to do other changes to work around that.
* SCO OpenServer - auditors stated that they expect to see logins blocked after 3 failed attempts on a terminal. Sure enough, when someone caused a terminal line to get locked, it blocked logins - but not on that physical device as nearly everything was on virtual lines over telnet. Whoever got the blocked virtual line got a failed login, and while they had that line in use, others could log in on higher numbered lines. Once the blocked line was free again, the next person to try would get a failure. Oh what fun to watch :)
Given this attitude from senior management, is it any surprise they will go behind the backs of IT and outsource things ? But who will they blame if anything goes wrong ? I think we all know the answer to that one !
I do agree that "sole ownership of copyright on code" is just daft (unless you are paying for all of it to be written of course). Third party audits may well be reasonable - it depends on who you are and what you have to comply with.
The first is probably imposed by some PHB, the latter probably imposed by some auditor who couldn't be bothered to ask anyone.
I've seen both sides of this
The business doesn't like IT involvement because they insist on contracts and compliance and all that boring stuff. JFDI. Then 9 months and hundred thousand pounds later the relationship the business has with their 3rd party is as bad as their relationship with IT. Calls in IT to help. Unfortunately all the documentation is held by 3rd party and is "confidential", no agreements, no SLA, no penalty clauses, nothing. The project then mires and attempts to take it in house or move to another third party are blockaded by the IP rights of the existing 3rd party. Trap! I've even seen whole developments writen off and the project kicked off again from fist principals with another third party because of this.
This only occurs when you have some seriously bad management taking place in your business.
But I've seen IT impose such restrictions on how business can take place on a daily basis you have to wonder why those "at the top table" allow it. IT, and specifically those parts of IT tasked with security and compliance can be seen as "the business prevention department".
As has been said up above by other folks quicker to keyboard than I, the point is to read the contract, understand what is in it, what are your legal responsibilities, etc. and act in the best interests of your business. If you don't understand the contract or the regulatory requirements then pay for someone who does to explain it to you.