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:


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.

This happened to me, going 10 days without a BT landline due to a major trunking cable being stolen. Hundreds of homes and businesses in the locality were without hardwire comms Once a new cable had been laid, all the individual customer lines, both business and residential, had to be individually reconnected and tested. There are many other examples, most recently the comedian Patrick Keilty on 6th September. Probably for a completely different reason, as there are many ways to lose a connection.

Yes, if the lines go down you can decamp to an internet café or another office. But at what point of waiting do you move all your filing cabinets etc to function fully and properly?  Larger organisations will have at least two routes into the internet from each premises.  It has been impractical for many smaller businesses. Remember that having two broadband providers that share the same BT copper to your premises does not cover the risk I mentioned. One option is to use Virgin cable. Another is 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. When I have a well-documented case, I’ll post it. The user's business benefit for SaaS of "pay less pay later" tends to put greater strain on vendor cash flows than on-premise systems.

With on-premise systems, in the short term the demise of a vendor is only a problem if support is required. And then very often the former staff are delighted to help for a fee. You’ll have recorded their mobile numbers of course. In the longer term, escrow arrangements for source code allow user groups to set up alternative arrangements for urgent mods, at least.

But with SaaS, the loss can be immediate.

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.

But an increasingly common approach is to use two separate vendors, with separate vendor chains. In some businesses, it is possible to use both systems live, perhaps by splitting clients into two groups. In most situations this is not possible. Alternatively it is possible to 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.

There is another benefit of two systems. They may be similar today, but may become quite different as they do (or do not) develop. Other options may become available over time, in which case the weaker of the two can be dropped in favour of a third.

With business critical apps, one on-premise system would be OK, as the risks can be managed easily. With SaaS, I would therefore recommend that you never use a business-critical SaaS app unless there is an affordable alternative available and in place. This means paying for two SaaS solutions for each business-critical app. But as the second one may only have one or two user licences until it needs to be used in anger, this is a minimal cost even for small businesses.


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 most cases username and password is likely to be sufficient. But does the SaaS vendor offer something more sophisticated for apps that 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. But it needn’t be that way. Madness!

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. It’s worth looking at the situation as a real life case study:

I had asked the vendor for two things:

1. To take part in beta testing, at no monetary cost to them or us, to trap issues that might otherwise be a major problem
2. Have control over when the upgrades were applied, so they didn’t clash with the major events we ran.

The SaaS company had won several major SaaS awards (or ASP as it was then termed). I was assured that their development and testing process was such that beta testing was not necessary. They told me all users were kept on the same release, all being upgraded at once “seamlessly”. And if there was perchance a problem, a fix could be made quickly. Yeah - and pigs can fly!

I had built a business with a number of partners who received an automated report at 7am each morning. Each was both operational and financial – a core part of the overall system. These were standard report formats, with aspects that were user-configurable and saved. As a large set of scheduled reports they were clearly visible to the vendor on its system. But they didn’t spot them.

I knew an upgrade was imminent, had been sent summary upgrade notes, but no detailed release notes (another issue!). There had been no chance to test the system. The first morning after the upgrade the reports didn’t run. Instead of adding a new report, they had introduced a new report that did a similar job. However it was two rows per record rather than one. i.e. we would have to set up a separate system to manipulate the reports and distribute them out to partners.

All would have been well if they had reinstated the original report, and changed their procedures so that we were involved in beta testing. Neither happened. As a start-up, we were still one of their smaller customers, with no clout. I was not prepared to put in effort to build the business and have it completely undermined by systems issues. With no reasonable alternative SaaS provider for the app in question (at that time), I could not continue with that “cloud” over my head. I therefore had no alternative but to stop using the system, and mothball the business in its infancy. It remains mothballed, pending a decision on whether to restart the events.

There are many other situations where reliance on the systems is just as critical. 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

Again this vendor was not prepared to consider such an approach. “That is the fee, that’s what you get”. Conversely 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. Not all vendors will be prepared to do it for a fee.

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..

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.