One of the major causes of the financial bubbles is derivatives. In theory, they're a good thing, but even though they seem very easy to understand, they're sometimes too complicated when things go wrong, and they can bring down entire companies.
We have something similar in IT: Software as a Service. In theory, it's a good thing. You can build entire companies on top of it, but even though it seems very easy to understand, it's sometimes too complicated when things go wrong, and it can bring down entire companies.
Many things can go wrong:
* Your provider may go bust. Needhost.dk just went bankrupt, and customers have no access to their data any more. There was no warning.
* Network connections deteriorate to a level where the software does not respond well enough to be usable. Almost no company provide enough metrics to be able to specify a minimum service level that solves all thinkable problems.
* Network connection bandwidth may deteriorate to a level where your data can no longer be transferred quickly enough to make backups or to move to another provider. And who knows, maybe your data is physically stored in Siberia?
* Power outage may hit one of the many connection points between server and client.
* The provider may not be able to allocate enough employees to help you out, especially if a problem hits all the provider's customers.
Usually, SaaS contracts are based on historical performance, like "our network has 99.9% uptime". They should write "had", because if uptime drops, the customer has a problem, no matter what the contract says.
Businesses usually rely on the fact, that if something goes wrong, there is usually a workaround. However, broken cables in the Mediterranean sea, or censorship can block entire ranges of IP addresses. Court decisions may block DNS names. If your country loses the connection to your SaaS provider, can your company continue without?
The solution to all this is easy: Make sure that your company can continue, if your SaaS provider stops its operations with no warning.
5 comments:
While you make some good points regarding SaaS, these are primarily mistakes made during the acquisition process - not a failure of the SaaS marketplace in general.
SaaS should be given no less diligence than a premise installed vendor.
One needs to understand their vendor's financial viability, market share, etc. so that you know they will be around for the long term.
Contracting with a SaaS vendor and without knowing where data is stored, how it is backed up and steps in case of the company's failure would be ill advised.
These are but a couple of issues that should be understood when making a SaaS choice. The issue here is how to be as knowledgable when making a SaaS acquisision as you are with a premise based system.
Kim Terry
Terrosa Technologies - The SaaS Solution Experts
I have seen many premise based systems in operation in organizations with more than 10,000 employees, where there is no longer support from the vendor. Often, the vendor cancels the support contract, but the organization continues to use the system, because the alternative isn't in place yet. Is this dangerous? Yes. But it's less dangerous than not having a system.
I have also noted, that some of the big outsourcing companies write contracts, that specify a lot about how data is backed up and how problems are handled, but they don't have the resources to actually do what the contracts say, and they don't do it. However, as long as the customer doesn't complain, there is no problem.
This one is completely impossible: "one needs to understand their vendor's financial viability". Madoff was the most financially stable around, and IT Factory went bankrupt at the time where Ernst & Young was going to give them a prize for being the best company around. Who knows, maybe we'll see CSC or IBM bankrupt next month? If that happens, don't expect to get access to your server quickly - there's a huge amount of paperwork to be done, and you never know what kind of paperwork there may be between you and your server. But you can be sure that there are not enough lawyers around to spend time on your problem.
When everything goes wrong, contracts will not give you access to your data. Physical access to your server will. That's why the server should be in your hosting center, if your company's survival depends on it.
I'm under the same impression about SaaS: it's an awful risk, with very limited benefits.
I might even venture that SaaS benefits are an illusion, similar to the complex insurance scjeme that surrounded derivatives. There were lots of insurance deals covered by lots of insurance deals, but in the end, the insurance deals turned up to be indirect cross-deals, and the actual insurance capability was negligible compared to the insured deals amounts, thus threatening to take down major insurance companies & banks.
IMHO this is the same about SaaS IMHO: the lower costs are an illusion, the guarantees are cheaper before they don't actually exist. Safeties are only there for minor isolated incidents, for anything bigger, the whole can come down pretty hard and pretty fast.
This is compounded by my experience about SaaS providers, which AFAICT have neither that many experienced people around, not as many redundancies as they should.
I entered into the ASP market in 1998 and watched half a dozen providers and their data centers go out of business. You do not loose your data, there are scheduled back ups, redundancy, and disaster recovery, and fail overs built into SLA's for both the ASP and SaaS business models.
SaaS is software delivered via the internet and accessed through an web browser network latency is not is a client issue.
This is not a new delivery model in fact delivering applications over the web is a legacy model; the metrics provided for minimum service level are generally between 97% and 98% up time.
Power outage there are fail overs; no issues.
Not enough employees-I don't know how to respond networks go down and I don't know any provider who doesn't have a switch over.
I've said enough; these comments are based out of inexperience.
Deborah, you seem to assume that a SLA is enforcable - that is not always the case. If the SaaS supplier goes bankrupt or loses key employees, or even if all customers want to restore their backups at the same time, the provider may be unable to service.
Also, I have seen lots of real-life latency times that makes Google Apps come to a halt - and if you want to mention SaaS, Google Apps is definitely a good example. For instance, a few months ago, the normal latency in Dubai was 350ms and packet loss was significant. Google Mail was barely accessible, but more advanced web interfaces were simply unaccessible. I don't know why it was like that - maybe their infrastructure didn't cope with the cables that were cut in the mediterrainean.
SLAs often give uptime larger than 95%, but there are seriously places, where internet uptime is less than 50% if internet uptime is defined as latency less than 500ms and packet loss = 0%.
With regard to power outages and failover systems, I know many failover systems that have failed. That's why many banks have outages, many credit/payment card systems have outages and that's why I saw a 100.000 employee organization which had to work for 8 full days without one of their main IT systems, even though it was designed perfectly, with 99.99% uptime SLA.
Company should be extremely careful, and usually not link their survival to the fulfilling of a contract by a SaaS provider.
Post a Comment