Social Media - What Can Location Services Do For You?

A couple of weeks ago I mentioned Foursquare, Gowalla and Facebook Places. These are all location-based services that you can leverage if you have a "venue" business - a theatre, a local shop, a shop in a national chain or any other place that people would visit.

So as a business, how can you take advantage of these services?

Let's look at how they work. The general principle is that people "check-in" to the place when they visit (although in  practice they only need to be nearby). They can then leave comments and tips, positive or negative  As a proprietor, this can be a great way of getting people "engaged" with your business, and spreading a good word.

But equally you need to watch out for any negatives. Having said that, it's not much different from any existing web forum where places are discussed - except comments are likely to be far more prominent on these location services than general forums.

When I wrote before, Facebook Places wasn't available in the UK, but it now is. Twitter has also got in on the act by allowing people to optionally tag their location to their tweets (additional to the usual 140 characters). Let's look at this first:


Twitter

Twitter is unusual in this set in that many tweets are made and read using a third party apps such as TweetDeck, which links to Twitter using an "API" interface.

Within  Twitter itself, there is the option in your account to "Add a location for your tweets". This is the "neighbourhood" you are in. The way this works is complicated, especially if you move around.

But if you are a local business it is worth switching this on, so that every tweet has your neighbourhood location tagged against it. . When someone reads a tweet for that neighbourhood, they can see a map of the neighbourhood and get the option to search all other tweets from that neighbourhood. That's when yours would appear.

The big proviso is that this new facility does not necessarily work to/from third party apps, so for the meanwhile is mainly limited to users of Twitter itself.. However if you can do it for your tweets, why not?

Facebook Places

Facebook provides a specific app to use on iPhones and other devices. A menu option is "Places", which uses the location your device is registering. This can be accurate to street and location within it.

By pressing "Check In" it provides a list of  places within about a kilometre to choose from. Or you can add a new place at the precise location you are at the time. When you check in you can add people who are with you, and then you get the option to "Like" or "Comment". However these flags do not seem to appear to people browsing from their iPhone (but probably will later).


The check-in with the comment do appear on your main Facebook wall, so your friends will see it in their news-stream.

Obviously this is useful for an individual to see when friend Joe has reached the local pub. But if you are in business how can it be used?

This Facebook page sets out how it can be set up for a business and linked to the business's page. But the comments from users suggest it isn't working properly, and there also seems to be an issue for any business with multiple locations. More importantly, it's not clear what you can do with it once you've set it up, other than provide information

Gowalla

This is actually a quick and easy way to see the various Google views (satellite etc) of where you are at that moment.

You can see "Spots" places up to about 3.5 km (2 miles), but only check into those up to about a km away. When you do you can add a comment which can optionally get posted to your Facebook and/or Twitter account.

There are "Trips" which are a collection of "Spots" that you can visit as a set, for example pubs in a town. Other than setting up a collection of your businesses into a Trip, it's not yet clear how a business might use Gowalla (can anyone tell me what they have in mind as I can't find anything quickly on their website)

Personally I find FourSquare much easier and more fun to use...

FourSquare

For some time Foursquare was "the only game in town". Literally, as it is a game - principally for towns. You collect points and badges. If you have visited somewhere more often than anyone else you become the "mayor".

The idea is that a venue can offer the "mayor" each day a free drink or some prize, and thereby encourage people to visit. However as you can check into anywhere up to about a km away, this is literally only a  game.

As the longest established location tool, most venues already exist on the system. It's easy to set up a new venue, and some people have set up their own house. That lets them be mayor - until someone who hasn't visited "ousts" them. Must be very disconcerting.to no longer be the mayor of your own home!

Foursquare is trying to compete with Facebook in  having its own "friends" . When you check into a place, you can add a comment and you can optionally tell your friends and/or Twitter, but not Facebook. You can also add "tips" e.g. "try the banoffee pie"

For your business Foursquare has a very clear webpage. There's also an increasing number of tips articles. 


In Conclusion


As an individual it's fun to use Foursquare. Gowalla does nothing for me, except the link to Google Maps. Facebook looks as if they have rushed out their location offering but it can be of some use. Adding a Twitter location can be fine, given it's only a neighbourhood.

As a business the ones to watch are FourSquare and Facebook, with Gowalla a distant third (at least in the UK). There's no harm adding a location to your Twitter tweets, which helps people find them when in the neighbourhood.

It's early days, but for businesses with shops and venues this aspect of social media can't be ignored, and could become very valuable. How are you going to leverage each of these services?

.

.

Escaping Excel Hell - Solutions for Planning and Forecasting

Last week I mentioned I was going to attend a seminar about a cloud SaaS-based planning, budgeting and forecasting system yesterday. I can now report that this system provides an attractive exit from Excel hell for these purposes

There were a number of general points made:

1. For a start-up business, flexibility in design of the financial model is key. But as the business becomes established and grows, very soon having a rigid structure becomes more important. 
2. However forecasting needs and business structures tend to change, such as with re-organisations. The modeling system must be able to cope
3. Whilst Excel provides ultimate flexibility, its drawbacks are significant - difficult to use in a multi-user situation, easy to get formulae wrong, difficult to roll up a consolidation, and needing constant checking (to name a few)
4. Would you use Excel for an HR or CRM system? So why for one of the most important functions of a business, its financial planning?

Well until recently planning systems of any note were the preserve of the richer businesses. These systems typically require involvement of IT personnel to make changes. This means planning users are then not able to control the model themselves, and more importantly when. No wonder many prefer Excel, where the model is all under their control.

Whilst there have been a whole string of systems that leave control in the hands of the users, these have tended to come and go as technology has changed. The power of Excel has killed off many of them, despite Excel's shortfalls. Just one or two of other systems of note remain.

A good planning system will provide:

1. Automatic consolidation roll-up (of regions, departments, business units etc)
2. Multiple dimensions (customer, territory, etc) that is just impractical in spreadsheets
3. Formulae applied consistently, such as working out employee on-costs
4. Clear data input sheets that won't break Excel
5. Easier version control
6. What-if on multiple sceanrios, far quicker than using Excel
7. Overall a substantial reduction in cycle time and cost, where the analysts spend less of their time on administering the system and more on planning and review

The cloud opens up additional possibilities.:

• One system that can be accessed for input and review worldwide, wherever there is an internet connection
• Encryption of the data and/or definitions, so that the "picture" can be kept confidential (no need to email Excel around for review on unsecure email)
• Strong backup and recovery potential - often lacking when using Excel

This particular cloud SaaS software can be run in the cloud on a shared database, or on a dedicated database. The latter allows the user to decide when the version upgrades take place - something to avoid in the middle of an intense planning process. The software can also be installed on the user's own internet server if required.

With a 3-user system around £2500pa (or £1500 for 1 user) for the basic version, this entry point means the power of a full corporate-grade planning system is now available to even a reasonably small business. It can also cope with many more users than that, and payment only follows need.

Whilst it is not sold principally as a reporting tool, it does include actual vs budget reporting, including dashboards.With the correctly-structured database behind it, you can drill down not only into budget detail but also the transactions behind the actual numbers.

If you would like to talk about this and other planning / forecasting system solutions, do contact me by email at challisc @ camwells.co.uk or by phone on +44(0)1628 632914

.

Business Performance Management - Forecasting and Reporting

To manage overall business performance you need to establish the metrics that are key to the business, plan them, and then monitor progress of them.

So the value of quotes raised may be critical. Or the activity on your website. Or whatever else is key to your business.

By setting targets, plans can be out in place for the resources and organisation to achieve them. Monitoring performance against targets is a key step towards control.

Obviously some form of system, is needed, preferably one that displays results on a dashboard. Tomorrow we'll look at a system that not only helps with setting the key targets, but also the detailed planning and subsequent reporting.that a business needs.

.

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.

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.

News Update Monday 13/9/10

Here's the pick of the last week's news stories:

Private Cloud - How could your business benefit?

Google Instant - How will it affect your rankings?

Malvertising - Watch out for innocent-looking adverts

For SaaS cloud vendors - Key metrics

.