He had taken his company's on-premise solution and converted it to run in the cloud. His customers have the luxury of sitting down with their SaaS provider to cover the service in minute detail. With customers that demanding, he knows absolutely what is needed for "business critical". He talked about "4 9s" and "5 9s" uptime, where unplanned downtime is essentially non-existent. We talked about what else is involved in running a business critical system.
We also talked about a number of other SaaS solutions he's involved with. At the other end of the scale is a system that typically cuts 30-40% off the freight costs of a distributor reliant on parcel courier firms. Whilst this can mean millions of pounds of savings to the distributor, a delay in processing isn't a big issue.
Two key conclusions from this:
- There are a vast array of SaaS applications out there, and plenty new ideas on their way. It is like opening a wardrobe full of great clothes - but you still need to choose the right app for the job..
- What each SaaS application needs to provide can be quite different. For example if you are looking at CRM (customer relationship management), accounting and a front-end business process like service management, different issues will be important. Comparison to the quality of any existing on-premise system is a key factor. It's a matter of "horses for courses" and "choosing the right cloud"
When choosing a SaaS app, the vendors will do their best to persuade you that what they are offering is "safe". "You won't need to worry about that", "We've covered that", etc, etc.
But how? In many cases you are well advised to delve that little bit deeper on certain issues, depending on the specific app and its business criticality.
Here are a few of the statements I've heard from SaaS vendors and cloud advocates that are worth a little further thought:
(1) “Security is not an issue” / “Security should not be an issue”
“Security” means different things to different people. I tend to regard it in two distinct parts:
- Access security, to stop unauthorised access either to view, take or damage data
- Backup and disaster recovery
Security is an issue for most new users, before they understand what goes on. Whilst it should not be an issue, the security standards in different parts of the SaaS cloud industry vary widely. If you are thinking of putting an app into the cloud, where the data and/or the processing is business critical, be sure to review providers carefully.
(2) “There has NEVER been a documented case of catastrophic data loss with a cloud service”
Keeping to the security theme, this phrase could relate to failure in access security or data recovery.
For data recovery, yes there has been at least one documented case sadly. About a year ago US telecoms carrier T-Mobile halted sales of the Sidekick cellphone after a server caused millions of customers to lose personal data
I also know of another unpublicized incident where the hosting provider hadn’t spotted that the backup had stopped working due to data volumes breaching a limit, so no backups were available when a recovery was required. There are undoubtedly more cases that have not been publicised.
Nonetheless cloud providers, through economies of scale, can usually provide a more robust computing environment than businesses can do for themselves on-premise, at least for smaller businesses. Many businesses do not have a disaster recovery plan, and if they do, how often is it tested? But equally what are the SaaS provider’s arrangements and testing frequency?
For loss of data from the database, it is not usually known for organizations to publicise such losses – indeed they probably don't know it has happened. However it’s also true that on-premise systems are often leaky. Customer databases are notorious, so moving to the cloud may even be an improvement in this respect. But you need to consider the specific app, and how SaaS compares to existing or potential on-premise systems.
(3) “We’ve had online banking for years, so SaaS security is OK”
Thinking of access security, the banks all have a different approach. Some use physical devices to generate codes and/or random letters, others random letters from passwords. In all cases the access mechanism is more sophisticated than just username and password.
Username and password is the typical level of security for remote access to on-premise systems. But there’s often a second stage to access each specific application. Depending on the app you are considering, is one level of username and password in a SaaS system sufficient?
(4) “Encryption for privacy of data will slow the system down too much”
Would you want someone working at the cloud provider seeing your data and taking a shine to it? Maybe sell the data to a competitor? There are at least two ways to adequately encrypt a database so that unauthorised access “through the back door” won’t work:
- Encrypt the whole dataset
- Encrypt just the definitions, and leave the incomprehensible data un-encrypted
Encryption is also more commonly applied to the data being transmitted to and from the server. Do you require this?
(5) “SaaS relies on multi-tenanted databases” / “There’s no security risk with multi-tenanted systems”
Many SaaS offerings are only available where some or all customers (“tenants”) share the one database. This makes it easier to manage, and therefore cheaper to provide.
But Sod’s Law says if it can go wrong it will go wrong. How long will it be before a report is produced with a mix of everyone’s data?
What techniques are the SaaS provider using to ensure this doesn't happen. Do they offer physical segregation on a separate server ? Some systems are available as single tenancy (at a price), or indeed to run on an internet server in-house.
(6) "Providers make sure they get things right, as their business depends on it"
So they should. However examples like those above and situations like BP in the Gulf of Mexico, show there can be incompetence or cost-cutting that jeopardises best intentions.At the very least you need to establish what the SaaS provider is officially doing, and not just take their word for it.
(7) “No consultancy is required for configuration, implementation or training” / “SaaS has a more modest implementation cost”
It’s certainly true that many, but not all, cloud systems are trying to make configuration as easy as possible. They are also trying to make the user screens intuitive. But so are the better on-premise systems. For a system of equivalent complexity, the experience of what set-up works best is equally relevant to cloud as to on-premise. The time and expertise needed is comparable.
Then there are all the implementation issues around change management, and specifics like data conversion. It is easy to get this all wrong. Once the system has been selected and configured, there is little if any difference between SaaS and on-premise for implementation.
Whilst many providers are encouraging you to do a DiY job, it’s best to assume an equivalent amount of professional help for SaaS at each stage as with on-premise. This is subject to the differences highlighted in these two articles on selection , where a quicker project can mean lower professional fees for SaaS, and implementation where similarities mean very similar professional involvement for SaaS and on-premise.
(8) “How many examples would you like for on-premise failures? SAP just settled with Waste Management on a $100 million failed project WM claimed cost them $350 mill on revenue etc.”
There’s no question that there are substantial failures with on-premise projects. This is typically because short-cuts are taken, and/or the people involved are inexperienced.
The same will undoubtedly be true with cloud computing, not least because the providers are telling buyers they can cut costs by cutting corners.
We’re already seeing specialist re-implementation consultancies for SaaS products used by larger businesses.. Unlike most computing, SaaS is working up into corporates from smaller businesses. As the projects get bigger, the cloud project disasters will start to happen. Not because it is cloud, but because of poor implementation technique.
(9) “Upgrades are smaller and easier to test. Nothing will go wrong”
This is often true, up to a point. But like on-premise software, there have been major problems where an upgrade has not been handled sensibly. Also the changes can be quite significant if the functionality of a relatively lite launch version is being expanded rapidly into a fully-fledged application.
In particular, any packaged software needs beta testing by members of the user community. Does this happen for the specific SaaS app? Can you take part in end-user "beta testing", to check the new app still works in a way appropriate for your business? Sadly critical problems have been known to slip through when there's been inadequate testing by end-users.
It also helps if the company has senior management experience of application development, rather than a hosting company getting into apps.
(10) “Cloud is Pay-as-you-go monthly billing”
As discussed in the earlier article, monthly billing is common, but is not always the case. It also varies whether you have to make a minimum commitment, such as a year, or can stop at any point.
Pay as you go billing can be a major issue for the IT providers, which in turn can become a major issue for you. Lump-sum payments for 1, 2 or 3 years may become more commonplace.
Depending on the app, there can also be scope for "gain share" agreements, where the SaaS provider earns according to savings provided, with or without a monthly fee.
(11) “SaaS offers a richer user experience and productivity”
This area is very much a matter of comparing one software product against another. There is no inherent advantage of cloud SaaS systems, except that they tend to be newer systems that may better use more modern technology, However that means they are less well proven than established offerings. You take your pick.
(12) “Utility computing models inherent in SaaS leads to more innovation”
Why? How? The innovation may come from the fact that new entrants tend to have less functionality than established offerings, and need to be developed to catch up. New entrants can also select new technology, rather than being constrained to decisions made some years ago. But as above, new means unproven. You have the option.
(13) “Data centre location is NOT an issue”
This is an issue in at least two respects, and if in any doubt seek legal advice:
- Data held outside of the European area is a Data Protection issue unless there is a special arrangement such as the US “Safe Harbor” scheme
- Any data held in the US is subject to the Patriot Act, amongst others. This give the US government powers of access to data that means the UK government, for example, is not prepared to hold UK citizens’ data in the US.
You can certainly scale up easily. Some systems let you adjust back down monthly. But many systems require a 12-month commitment to any increase, which makes scaling back down more difficult.
IN CONCLUSION
There’s no doubt that SaaS cloud computing can provide significant benefits. It’s just a pity that some of the SaaS advocates are trying to hoodwink you into using the cloud by using misleading statements.
Nonetheless, by working with the right SaaS providers, in the right way, these and other risks can be tackled and the benefits realised consistently.
So what’s next for your systems?
.
No comments:
Post a Comment