Suppliers and evangelists are enthusiastically promoting the wholesale migration of corporate IT into the cloud; what appears to be a simple suggestion hides a set of complex trade–offs.
It’s true that mobility continues to grow, that we are enthused by new consumer technology, and that work and play are not sharply distinguished. At work we are increasingly demanding the ability to access our applications and our data anytime, anywhere, quickly and easily, and from the device of our choice.
There are some fundamental differences between services which work well delivered by Cloud providers (Multi–tenant Software as a Service), and those which are provided and supported internally (often from your own data centres). Most of the differences have to do with the management of the trade–offs, however, not the underlying technology. For example, a heavily customised Siebel platform tailored to work exactly to your requirements is a different proposition from a Salesforce.com solution that delivers standard functionality covering approximately 80% of what you would idealy like, but which forces you to change to fit the remaining 20%
Solutions running from the cloud are typically simpler, and provide many advantages when it comes to automatic upgrades and changes. Increasing capacity due to volume growth is simplicity itself, and typically cloud product providers look to release new features two to three times a year, but other kinds of changes may have to wait until some other customers also decide they need them. Providers may also be on the lookout for changes that are being driven by new technologies that have passed individual customers by. For example who was designing applications two years ago that needed to cope with Twitter?
There is also an operational perspective on Cloud–based services. Whereas internal solutions can have variable levels of resilience, Cloud Service Providers must design their solutions from day one with very high levels of resilience, as it is their entire business! One system going down is a drama, 1000 businesses going down is a crisis. However, moving operations to someone else’s Cloud involves some more trade–offs; administration accessibility, transfer of technical and operational risk, but much reduced set–up costs and significantly faster implementations.
Smart businesses should consider where they would get the biggest benefit; Which initiatives and projects would benefit from Cloud–based services? Which operational services are best delivered from the Cloud? Which application services are best delivered by a SaaS provider? On the face of it generic application services should be procured from a cloud provider (e.g., email, CRM, accounting, HR) rather than very company specific services, especially if that very bespoke solution is believed to give some competitive edge. Whether to use external hosting (and any ancillary services) for those bespoke services is another question.
In part these decisions will depend on the segmentation you need to make – of those people who really need to access all their applications and data anywhere any time using any device. Device independence isn’t a slam dunk.
Having to access applications and data run by a third party and over the internet brings a number of specific security questions to address. Some regulated businesses can’t use Cloud–based services without specific restrictions, and many operational service providers won’t be able to say exactly where the data is at any one time (However, Salesforce.com has just announced options to address this issue). So it might not be an option for you. In general however, this model turns the traditional security approach on its head. Traditionally, security focussed on a thing: it might have been the network periphery, or the server, or the end point, but the lock down focussed on some object that was owned or controlled by IT. Once services are virtualised and device independence is granted, security can no longer focus on any object, but instead must secure the service.
Device independence often goes with browser independence (or at least much greater independence than many internal IT departments would wish to grant) and this may be extremely hard to achieve for many highly configured applications. Again, it is crucial to understand the segmentation, and the trade–offs that might need to be made here, especially in the light of some of the possible costs to enable the migration.
Outsourcers have argued for years that they can turn fixed (capital) costs into variable (operating) costs, and no doubt this has its appeal (depending on the trade–off between self–financing and using the outsourcer as a bank); certainly buying services from a provider who has massively more economies of scale than you do, and who can smooth the peaks and troughs of demand is at first blush attractive, and being able to walk away (or downsize without stranded costs) is pretty much always an advantage. Cloud–based services take this concept one stage further, with their straight line cost per–user–per–month models, typically with notice periods of between one and twelve months only.
However, we can’t assume that the economics of Cloud computing will win the day, as there is always a trade–off between paying for something you might not use (your own data centre, or investing in servers and a high number of seat licences for an application before implementation starts) and paying for only that which you do use (the Cloud’s capacity) plus the profits of the provider and the relative costs of capital. This in turn will depend on your estimates of your need for growth (or reduction) over the planning cycle.
It is likely there are many and varied opportunities to be had by exploiting new models of technology and technology service provisions (often unhelpfully just called “Cloud Computing”). But they need identifying, and working through, if you are not to be the victim of just the next bit of marketing hype.