Cloud Computing - BIGGER BENEFITS, BIGGER ....

…OPPORTUNITIES. You probably already know that the cloud SaaS (Software as a Service) can provide tremendous benefits to your business. But as Intellect the computing trade body says “While the SaaS model offers significant advantages over on-premise, it does carry potential risks that must also be considered” 


Realistically you’ll only be able to reap the benefits of SaaS on an ongoing basis if the risks are managed down to an acceptable level. Otherwise Sod’s Law says something will go dramatically wrong sooner or later. The consequences are grave embarrassment or major business problems.  Or both.

The good news is that risk management can now be done adequately in all areas, as outlined below. Some risks are very unlikely, but when they happen can be catastrophic. I know the pain - I had to mothball a business in 2006 that was dependent on a cloud-based trading system that I could no longer trust. These days that simply shouldn’t be necessary, working with the right cloud suppliers and with a professional approach from both supplier and user.

I’ve just had a long chat with a senior member of the cloud system vendor community (name and address supplied), focusing on SaaS. He had taken exception to the headline I’d used in a previous article “BIG BENEFITS, BIG RISKS”. Both of us have many years experience in all aspects of on-premise and cloud apps, and we basically agreed on everything – as long as I replaced “BIG RISKS” with “SIGNIFICANT RISKS”. So I dropped it from the headline altogether, as you’ll see above.

With him approaching as a vendor, and me as a user, we specifically agreed:

1. Many people talk of a “hybrid” set of apps using both on-premise and cloud solutions. However there’s no good technical or commercial reason today why it shouldn’t be possible for all apps to be cloud based in any organisation large or small. It’s just a matter of vendor/app quality, plus a suitable approach to using SaaS by the user
2. Given the cost and practical advantages of SaaS, it should be a no-brainer for user organisations to use SaaS solutions for virtually any app, regardless of sensitivity. However buyers need to know which vendors are up to scratch, and also how to handle risks which the vendor can’t handle, such as continuity of user’s telecoms access to the internet
3. Currently “best practice” within the cloud industry does not deliver that vision, and there is significant scope for improvement
4. A lot of purchasers are currently quite rightly wary of SaaS. Personally, given the variety in the quality of vendors out there, I have been and remain “Positive But Cautious”
5. For some apps, the benefits far outweigh the disadvantages and risks. CRM (Customer Relationship Management) is a good example in some situations. Businesses that are using spreadsheets and paper records for customer details probably hold their data less securely than they would  in the cloud, so in that respect would benefit immediately
6. However the key issue for purchasers is loss of control, especially for apps such as accounting that are already (apparently) well-controlled in-house. This is not dissimilar to any outsourcing arrangement, and people have been outsourcing apps like accounting for years. [I’ve worked with the outsourced shared service centre for the BBC, for example, which involved outsourcing not only the system but the whole back office financial processing. I’ve also worked with plenty of business people whose business is their baby, and outsourcing is not something they consider lightly.]
7. Buyers typically have a fear of the unknown – because they simply don’t have the experience of SaaS, or where they have identified a risk and aren’t aware of a practical solution
8. We both would like to see the SaaS industry generally at a “best practice” level that makes buying SaaS a no-brainer, subject to due diligence on the vendor to confirm
9. Vendors need to do better communicating how they handle the risks (as well as understanding and dealing with them better in the first place)
10. If vendors want to make it easy for people to buy, they should also help to educate the user community, and thereby overcome their FUD (Fear, Uncertainty and Doubt). Consultancies such as Camwells can also help, hence this article.

Many people are now familiar with the benefits of cloud SaaS, as vendors are especially good at highlighting them. Key benefits include worldwide access, faster implementation,  typically better disaster recovery, and lower costs. More benefits are in the original Hot Air or Business Reality article.

But as a user, my main concern is that I’ll come in one morning and find one or more of the apps unavailable for some reason. If the app is business critical, that will be a problem, potentially major. Potentially catastrophic. Let’s look at some of the main issues and how to manage them: (see sister article for full details, as this is just a summary)


User Issue - Internet Access

In the user’s red corner is internet access. I’ve quoted Andy Scott before as saying “Loss of Internet = loss of information systems. PERIOD.” Not a comfortable or useful position to be in if your business is reliant on email and the internet to function, especially using cloud applications.

It's worth having at least two methods of getting internet access, choosing from:

1. BT or another broadband providers sharing  BT's cabling, bearing in mind that using two such providers doesn't help. A private connection rather than public provision is preferred, subject to cost
2. Virgin cable. 
3. The new MiFi units, provided you have signal coverage and enough WiFi-enabled laptops and PCs in the office

User Issue – Supplier Resilience

What if the supplier goes out of business? Not necessarily the SaaS vendor, or even the hosting company they use. But are there any other businesses in-between? Stories are coming in of middlemen not paying their hosting bills, and end-users being cut-off with little or no notice.

To avoid problems, first of all you need to carry out due diligence on the vendor chain. Thereafter you can monitor each company in the chain for financial delinquency.

You can also use two separate vendors, with separate vendor chains:

• Perhaps by splitting clients into two groups. 
• Have a second system configured up and ready to go, with a quick data conversion written and tested. You just have to ensure that a data extract is done regularly, at least daily, to facilitate the transfer.

Running two systems lets you choose which is better and possibly replace one with a third if that later proves better.



Vendor Management

It’s worth checking that the management of the SaaS vendor has plenty of experience of software apps. Vendors that do their own hosting, and are in fact principally hosting companies, will not necessarily understand the app issues. In the rush to get releases to market, will they bypass essential beta testing, for example? That’s my experience.


Vendors – Business Continuity

Professional hosting companies know all too well about multi-site redundancy, database mirroring, physical security, disaster recovery and all the other techniques to keep systems running 24x7 without the risk of data loss.

Whilst this cannot be taken for granted without due diligence, this is usually well handled. Certainly it is one of the big benefits of SaaS compared to on-premise, where all too often backup, recovery and disaster recovery arrangements are less than ideal – or non-existent.


Vendors – Access Security

I’ve heard it said that “We’ve been using eBanking systems for years, so security isn’t an issue for SaaS” or words to that effect.

Apples and pears. The eBanking systems have multi-level access that even at its simplest is username and password plus at least one more aspect, such as a PIN, a second password, or a physical card reader. Biometrics such as retina recognition may not be that far off.

For SaaS, in many cases username and password is likely to be sufficient. But does the SaaS vendor offer something more sophisticated for apps you feel need it?


Vendors – Database Encryption & Partitioning

We’re used to sending spreadsheets containing highly confidential or valuable data through internet-based email systems, with no encryption. Or we put data onto dongles and laptops, and then leave them on trains. Madness! But it needn’t be that way.

There are SaaS providers that encrypt the flow of data to and from the user’s device, and also store the data encrypted. This can be done in two ways, depending on performance needs:

• Full encryption – for example for secure data rooms
• Encryption of the wording and definitions, but leave the numbers unencrypted (as they make no sense without labels) – such as for business planning and accounting

In database structure, SaaS systems tend to work in one of two ways:

• Sometimes: Each user’s data is in a separate database
• More commonly: All users (or a significant number) have data in one shared database. This means every input, enquiry and reporting program must reliably only give a user access to that entity’s data. Sod’s Law says that if it can go wrong, it will go wrong, however careful the vendor’s programmers are. Imagine getting a report with all the other users’ data in it, knowing that they can all see yours!

There are also performance disadvantages in having one large database instead of several smaller ones, depending how they are distributed across the servers. Vendors that have dedicated databases, or offer that option, are inherently better.

The key is to understand what you will be buying, taking into account the next topic, which is inter-related.


Vendors – New Releases

New software releases are completely different with SaaS compared to on-premise.

On-premise software is typically updated no more than once a year, perhaps with some extra bug fixes in-between. This is for two reasons

• Distribution of the software via some type of physical disk is a major exercise, although in recent years this has increasingly been done via a datalink
• Every user’s installation is different, and each release may have to be tested in 10, 20 or more different environments.

SaaS systems are far easier:

• There’s only one central system to test
• The vendor can see directly how the software is being used (or how he thinks it is being used)
• Releases can be made more frequently, at a time that has little or no impact on the userbase
• These smaller releases are easier to test
• Users don’t have to bother about upgrades, and keeping on the latest release is marketed as a major benefit of SaaS
• Lower release costs translate into lower software and support fees, another benefit

However users should very carefully understand how upgrades are done as part of the procurement process:

• Do they have a “beta testing” process? Can you take part? Traditional software development involves a small number of real customers trialing new releases. This will find practical issues which the author’s programmers couldn’t be expected to foresee.
• Beta testing also helps to trap new bugs which inevitably creep into any new piece of software, before they go live. The more testers the better. Yes fixes in live SaaS production systems can be made quickly and easily, but that could be too late.
• When do upgrades take place? Many business processes have peaks and troughs. There are times that events or deadlines mean you want no changes to systems, so there is no confusion to staff, and no risk of anything going wrong.
• Can you control the timing of releases?

It was this issue over upgrades that led me to have to drop a SaaS system and, with no credible alternative, close the business that was using it.

Whilst it is rare these days to have an app where there is only one affordable vendor, it is still a major hassle to change systems. A vendor that offers beta testing is therefore highly preferable for any critical applications.

The other issue is timing. Having everybody on the same release makes support so much easier and cheaper. That’s good news for users, assuming it is reflected in lower rental costs. However would it not be possible to have two systems with the old and new releases for a short while, maybe 3 weeks or months? Then:

• Users could decide when best suits them to upgrade
• Users could avoid upgrading until issues found by testing or other live users have been fixed

Talking to a US vendor this week he said “If you want that it will be $25,000”  Prohibitive for a smaller company, but good value for a larger one.

But upgrade flexibility, using just two versions of the software, ought to be a standard offering, albeit as a “gold” version of the service. There has to be technical approaches that deliver this result at little if any extra cost to the vendor or user. Until it is standard, watch out for those vendors that offer upgrade flexibility. They are also more likely to offer better-segregated databases, as the two aspects are inter-related.


Other Issues and Initiatives

I have also been involved with many on-premise systems over the years. Running business-critical systems with reasonable user numbers, I’ve found that we needed to do a number of things (in addition to backup and recovery, which was inter-related):

• For a new software release we didn’t just have to test new software, we needed to understand what new data fields had been introduced that needed to be populated, how existing incomplete sale and purchase transactions would be handled, and revise user procedures where necessary. This needed a separate data partition into which a copy of the live data could be copied to test with the new software
• There were also times when we needed to try out something new in the live system, so set up a separate copy to trial on the live software
• There was also user training. This needed a copy of the latest software (live or in test), but with a dummy set of data.

So we ran four databases (live, trial, train and test) with two software versions, different data sets and facilities to copy data from one to another. Any vendor that doesn’t provide that for business-critical systems of any complexity is not providing what we found was needed. Currently this is not a standard offering in the SaaS market. Some vendors will be prepared to do it for a fee, but not all.

The more proactive vendors are actually going a step further. They are looking at apps in modules that you buy like apps in an AppStore. This requires different database and system designs, and therefore might require a total re-write. This is a golden opportunity to incorporate these other user requirements, where necessary changing the underlying database to one where licensing costs are not prohibitive to this vision..



Other Issues

I haven’t had chance to cover every issue, such as inter-app integration and Data Protection Act constraints. The DPA is an area which is likely to be changing within the time horizon of using a system purchased today, so it’s worth thinking ahead. Further details are in earlier articles


Conclusion


Today “best practice” in the cloud SAaS industry is good enough for non-critical apps, but on the whole the apps are not fit for business-critical situations. Nonetheless a few notable vendors are providing systems that are suitable, and they are leading the way.

User organisations therefore need to approach the use of cloud SaaS apps with some caution, and consider the vendor options carefully. Users also need to be aware that there is much they need to do themselves to cover risks that the vendors cannot do for them.

But with the right vendor and the right approach to cloud SaaS computing, it should be possible to move all apps into the cloud to unlock the substantial practical and cost benefits.