Dale Vile, originally published on Computer Weekly
Cloud computing is frequently likened to utility services such as electricity, water or gas. If all that’s being consumed is compute cycles or storage space, then this analogy can be useful to understanding what’s on offer.
The ’on-demand’ principle of consuming just what you need when you need it is common to both types of service, as is the ability to switch providers with relative ease when required.
Things can be often be very different, however, when it comes to business application functionality delivered via the so called software-as-a-service – (SaaS) model. If it’s a customer relationship management solution, for example, the way it works is likely to become ingrained in your business, with elements of the service becoming intimately intertwined with your business processes.
If you invest time, money and effort in a lot of setup and configuration during implementation, as is par for the course with more complex application services, this dependency becomes stronger. Even with something apparently as straightforward as an e-mail and collaboration service it’s amazing how much of your workflow, security and other information- and process-related policy becomes embedded in the system.
The upshot is that unlike utility services, switching SaaS providers is likely to have an impact well beyond the price you pay and who sends you the bill. Moving from one provider to another, or bringing an application back in house, can involve significant cost and disruption. With this in mind, effective due diligence before committing to a service is critical. And here’s the rub. Cloud rhetoric often creates a false impression of flexibility, which can in turn encourage customers to short-cut or even bypass the checks and balances they would normally apply when making decisions.
So what needs to be considered? The fundamental principles here are no different to the selection of important on-premise software. Some SaaS-specific considerations exist that we’ll come onto in a minute, but it’s worth recapping on the discipline typically used to evaluate a key application package. This is a much better point of reference than utility service selection.
Making sure the solution is a good fit functionally and technically is obvious, but experience over the years highlights many dangers and pitfalls. Making assumptions is one problem, and this can can easily lead to disappointment. You might think a modern customer relationship management (CRM) system would naturally support the latest mobile technology, but that’s not always the case. And we all know that sales reps are sometimes ’economical with the truth’. The solution might well be capable of integrating with your accounting system, but finding out later that 20 man days of professional services or a third-party component is required to achieve this is a nasty surprise.
None of this changes with SaaS. In fact it could be argued that the risks are higher. While we have seen a lot of consolidation in the traditional application marketplace, the cloud space is littered with startups whose services are sometimes based on half-baked and largely unproven home grown solutions. There are then providers who started out with lightweight consumer-class services now opportunistically targeting the business sector with solutions that are not anywhere near ’enterprise-ready’ from a security, access and management perspective.
Choose your supplier with care
Beyond the solution, attention must also be paid to the supplier. Evaluating substance and stability (e.g. financially) is again pretty obvious, but staying-power is even more critical with SaaS. With an on-premise solution a supplier going bust may create a support and maintenance problem, but if it’s SaaS, the service could close down with much more serious and immediate consequences.
The cultural dimension is important too, not so much the touchy-feely stuff such as “putting the customer first” or “becoming a strategic partner” as the supplier’s core values and how these manifest themselves in tangible ways that affect customers. Examples here are policies around licensing, pricing, maintenance and support, and what happens when things go wrong or disputes arise. The degree to which the needs of different industries and company sizes are taken seriously is another consideration.
Turning to SaaS specifically, an extra set of dependencies and constraints exists as a result of limited customer control over the application environment. What happens, for example, when a major functional upgrade or change is made? Are all subscribers forced to take it on at the same time? And what about frequency of upgrades and whether a road map is published to support forward planning and preparation? While trickling out ad hoc updates on a continuous basis may suit some customers, others may prefer changes to be batched up so they can move from one ’release’ to another in a more controlled manner.
Providers vary a lot in terms of practices in this area, and a mismatch can lead to issues around integration, compatibility, compliance and managing users’ expectations. We could go on to talk about the importance of alignment on security policy, data protection, user support, and other things that will be dependent on the nature of the service and provider delivering it. The point is that with SaaS, the system does not belong to the customer, and that has consequences.
But let’s not run away with the notion that SaaS is totally about getting what you are given. Many providers make facilities available which allow self-provisioning of users and features, ’soft’ configuration and tailoring of the service, and effective management of security and access. This goes quite a way towards ensuring that control is maintained in the customer’s hands for most day-to-day requirements. SaaS providers also come in all shapes, cultures and sizes, so the chances of finding an organisational soul-mate are pretty good if effort is put into shopping around.
Get it wrong, however, and the risk of being stuck in the equivalent of a bad marriage is significant, and escaping from the situation could be both expensive and disruptive.